linux-l: Ist /etc/group wirklich so limitiert?

Joachim von Thadden thadden at running-systems.de
So Sep 5 22:55:04 CEST 1999


Ralph Angenendt wrote:
> 
> On Fri, Sep 03, 1999 at 03:48:33PM +0200, Philipp Grau wrote:
> > On Wed, Sep 01, 1999 at 09:08:27PM +0200, Ralph Angenendt wrote:
> > Es ist keine solche "variablen"-bezogene Schreibweise moeglich,
> > aber natürlich geht:
> >
> >       Arbeit:x:501:dirk,peter,heinz
> >       Gaeste:x:502:micha,karl,gerd
> >       Freizeit:x:503:dirk,peter,heinz,micha,karl,gerd
> 
> Das ist mir klar, ist aber bei großen Nutzergruppen einfach nur
> Müll, es ist ziemlich viel Aufwand, das groupfile überschaubar zu
> halten.
> 
> > > funktioniert nicht, ist mir heute aufgefallen, daß unter Linux ein
> > > User nur in 32 Gruppen gleichzeitig sein darf.
> >
> > Stimmt, aber ich sehe eigentlich auch nicht so recht, an welcher
> > Stelle ein Nutzer in mehr als 32 Gruppen Mitglied sein sollte.
> 
> Och, ein mittelgroßes Unternehmen mit einer sehr filigranen
> Rechtevergabe auf Projekt- und Arbeitsverzeichnissen kann so ein
> Problem schon mal haben - vor allem, wenn es zwei oder drei User
> gibt, die per Definition auf ziemlich viele dieser Verzeichnisse
> zugreifen dürfen, aber eben nicht auf alle. Da sind 32 Gruppen
> wenig.
> 
> Ich bin ja schon froh, daß wir da Samba laufen haben und kein NFS,
> dort werden nämlich nur die ersten 16 Gruppen übergeben, und das
> könnte noch mehr Probleme schaffen.
> 
> Na gut, setze ich mich halt mit denen hin und schreibe das
> Gruppenkonzept um. Hrmpf. Da kann NT ja wirklich mehr als Linux.
> 

nee, dafür hast'e ja Samba und kannst Deine Rechte pro Share so
detailliert vergeben, wie Du virtuelle Tinte im Compi hast.


> > Und denkbar ist auch der Einsatz von Tools wie super oder sudo, die
> > eine sehr feine Differenzierung der Ausfühungsrechte für Programme
> > erlauben.
> 
> Wenn es um Programmausführungsrechte ginge, hätte ich wahrscheinlich
> zwei bis drei Probleme weniger.
> 
> Ich habe mittlerweile rausgefunden, daß man in
> include/linux/limits.h dem Kernel beibiegen kann, daß es mehr als 32
> Gruppen gibt, die glibc2.0 muß auch leicht gepatcht werden, ich bin
> mir aber nicht sicher, ob danach noch alle Programme funktionieren,
> da die eventuell die dort gemachten Vorgaben fest einkompilieren
> (login wäre so ein Kandidat - andere Programme, die die
> Gruppentabelle auslesen eventuell auch).
> 
> Die glibc2.1 orientiert sich wohl am Kernel, aber auch dort muß
> wahrscheinlich die ganze Distribution neu übersetzt werden -
> eventuell hätte man doch FreeBSD für den Job nehmen sollen ;-)
> 

Wenn Du das wirklich so brauchst und es vor allem auch pflegen kannst
(stöhn!!!), dann mußt Du auch nur die Programme evtl. neu compilieren,
die Ihr verwendet und die sich um Gruppen überhaupt kümmern... das ist
eine sehr übersichtliche Anzahl und nur diese ist neu zu übersetzen.
Eine ganze Distribution wirst Du wohl kaum jemals unter irgendwelchen
Umständen übersetzen müssen.

Wegen der oben angesprochenen Pflege rate ich allerdings DRINGENDST, das
Gruppenkonzept noch mal zu überdenken und alte Hüte dannn doch mal über
Bord zu schmeißen....


> Ralph
> --
> Two computer people discussing those old stories about Bill Gates'
> name adding up to 666 in ASCII: "I hear that if you play the NT 4.0
> CD backwards, you get a Satanic message!" "That's nothing. If you
> play it forward, it installs NT 4.0!"        --John Horner

-- 
Mit freundlichen Grüßen/Sincerely
	Joachim von Thadden
    "Never run a touching system!"

-------------------------------------------------------------------
Running Systems					LINUX-Systempartner
Qualified Helpdesk   .   Netzwerkbetreuung  .   Sicherheitskonzepte
www.running-systems.de			        fax (030) 801 74 23
thadden at running-systems.de		     phone (0177) 717 08 96



Mehr Informationen über die Mailingliste linux-l