Glaub ich eigentlich nicht. Das Problem ist doch die Abfrage, wenn definitiv gar kein Passwort da ist.

na ja, in shadow ist das "default" Password auch ein unmögliches, z.B. "*" oder "!" oder sowas, vielleicht ist das bei gshadow einfach mal genauso?!

Sonst müsste in der /etc/group was zu finden sein oder wo sollen sonst die Einstellungen für die Gruppen stehen?

Passworte doch in /etc/gshadow !? Ich habe diese Feature (primäre Gruppe setzen, wenn Mitglied) noch nie gebraucht. Umgekehrt ok, z.B. passwort für Gruppe dialout oder so. Nur mal interessehalber: Wann braucht man das? oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

Hi, On Tue, Nov 30, 1999 at 17:57 +0100, Ulrich Klaus wrote:

Wenn zwei Nutzer Mitglied von 'users' sind, und gemeinsam Dateien bearbeiten moechten, koennte man ein Gruppe 'ag' (oder so) einrichten, und die betreffenden Dateien werden dieser Gruppe mit Schreibrechten zugeordnet. Normalerweise sind diese Nutzer aber mit der gid von 'users' eingeloggt, d.h. neu erzeugte Dateien haben eben diese. Man muesste also erst ein 'chown :ag *' (oder so) ausfuehren, damit der Nachbar auch ran darf. Wechselt der Nutzer aber vorher in die 'ag', faellt das weg (und die Nerverei, wenn man das chown mal vergessen hat). Gibt es eine bessere Loesung dafuer?

Ja, soweit ich weiß, verwendet RedHat folgendes Schema: Es gibt keine Gruppe users, statt dessen wird für jeden neu angelegten User eine eigene Gruppe erstellt. Die umask wird auf 002 oder 007 gestellt. Sollen jetzt mehrere Nutzer gemeinsam Dateien bearbeiten, wird eine Gruppe für sie angelegt (z. B. ag) und ein Verzeichnis, in dem sie ihre Dateien ablegen. Das Verzeichnis wird der Gruppe zugeordnet und bekommt das sgid-Bit gesetzt: mkdir ag_dir chgrp ag ag_dir chmod 2770 ag_dir Damit gehört jedes neu angelegte File in ag_dir automatisch der Gruppe ag und da die umask auf 007 oder 002 steht, werden die Rechte immer so gesetzt, dass alle Mitglieder von ag Zugriff darauf haben. Ciao, Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

Hi, On Tue, Nov 30, 1999 at 20:43 +0100, Steffen Dettmer wrote:

...

Ja, soweit ich weiß, verwendet RedHat folgendes Schema: Es gibt

U*NX, zumindestens Linux, nicht nur RedHat :)

Gemeint war damit eigentlich nur, dass bei RH für jeden User automatisch eine eigene Gruppe angelegt wird (lt. iX 7/98). Dass das ganze Prinzip generell mit Unix/Linux funktioniert, ist mir schon klar :-)

...

chmod 2770 ag_dir

== chmod g+s cvsroot/, ja? Habe die höheren Nummern nicht im Kopf :)

Jepp. Ciao, Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

Hi, On Tue, Nov 30, 1999 at 22:50 +0100, Steffen Dettmer wrote:

Das ist dann aber bei 5.x noch nicht so gewesen, oder? Na, und

Doch, eigentlich schon. Der iX-Artikel, aus dem ich das habe, handelt von RH 5.0.

ich frage mich, ob das soviel Sinn macht. Erfahrungsgemäß sind doch solche Sachen eher die Ausnahme, und wie sieht es aus, wenn stefan in Gruppe steffen ist, weil wir ein CVS Rep zusammen benutzen?! Oder wo liegt der Hintergrund?

Das Anlegen einer eigenen Gruppe für jeden Nutzer hat damit eigentlich noch nicht viel zu tun. Das Problem ist doch folgendes: Normalerweise arbeitet man mit einer umask 022 oder so ähnlich. Auf keinen Fall steht an der zweiten Stelle eine 0, d. h. wenn man Files anlegt, haben Mitglieder der entsprechenden Gruppe keine Schreibrechte. Für die Files im eigenen Homeverzeichnis ist das auch OK so. Arbeitet man jetzt mit anderen an einem Projekt, in dem jeder gemeinsame Files anlegen und verändern kann, muss man entweder mit chmod dafür sorgen, dass die Kollegen Schreibzugriff auf die gemeinsamen Files haben, oder man setzt laufend seine umask um. Mit dem System mit der eigenen Gruppe für jeden User kann man sich das sparen, da man seine umask permanent auf 007 stellen kann. Die Dateien im Homeverzeichnis kann damit niemand außer einem selbst lesen, die Dateien im Projektverzeichnis kann jedes Projektmitglied lesen/schreiben, da diese Files alle einer gemeinsamen Gruppe gehören (sgid-Bit für das gemeinsame Verzeichnis gesetzt), und aufgrund der umask 007 automatisch Lese- und Schreibrechte für diese Gruppe gewährt werden. Klar? Ciao, Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

Hi, On Wed, Dec 01, 1999 at 11:40 +0100, Bernd Brodesser wrote:

Aber dafür ist es doch nicht Notwendig, daß die Gruppenmitglieder irgendeine Gruppe zu einer aktiven machen. Wenn Du jedem User eine eigene Gruppe gibst, so trage sie im vierten Feld von /etc/passwd ein, die GID meine ich, und gut ist. Alle Mitglieder Deines Projekts bekommen sind dann noch in der Projektgruppe. Dafür brauchen sie doch ihre Identität nicht zu ändern.

Das habe ich ja auch nicht geschrieben, oder doch? ;-) Das ganze Hin- und Her mit der eigenen Gruppe für jeden User (die natürlich dann auch in /etc/passwd im vierten Feld steht) soll nur dazu gut sein, dass man seine umask permanent auf 007 stellen kann, egal, ob man gerade eigene Dateien bearbeitet, auf die man nur selbst Zugriff haben soll, oder irgendwelche Projektdateien, auf die mehrere User zugreifen können. Das funktioniert, wie Du geschrieben hast, auch, ohne newgrp benutzen zu müssen oder chown/chmod. Ciao, Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com