funktioniert net so, wie ich das will
Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Gruppenrechte
hi,
ich will mit gruppenrechten ein verzeichnis öffnen. irgendwie scheint irgendwer nicht zu peilen, dass ich vorher /etc/group geändert habe:
kabel@debian:/var/lib$ ls -ld cvs
drwxrwx--- 4 root cvs 4096 Feb 10 2004 cvs
kabel@debian:/var/lib$ whoami
kabel
kabel@debian:/var/lib$ groups
kabel audio images
kabel@debian:/var/lib$ groups kabel
kabel : kabel audio images cvs
kabel@debian:/var/lib$ ls cvs
ls: cvs: Permission denied
kabel@debian:/var/lib$wenn sich nun plötzlich die gruppe ändert, und zwar in eine, die das kommando groups ohne argumente anzeigt, dann funktionierts:
kabel@debian:/var/lib$ ls -ld cvs
drwxrwx--- 4 root audio 4096 Feb 10 2004 cvs
kabel@debian:/var/lib$ ls cvs
CVSROOT etc
kabel@debian:/var/lib$anyone?
tia
btw ich bin mir ziemlich sicher, dass es nach einem neustart funktioniert, aber es ist zumindest ein interessantes phänomen 
update-passwd auf Debian-Systemen 
Das hilft aber nicht direkt bei deinem Problem. Deine Shell (der Prozess) lief vermutlich schon bevor du die Gruppen geändert hast (daran zu erkennen, dass groups ohne Argumente die Gruppen des ausführenden Shellprozesses verpasst bekommt … groups mit Username als Argument zeigt die tatsächlichen Gruppen des Users an). Diese Änderung wirkt sich aber nicht auf bereits laufende Prozesse aus … mit “newgrp” kannst du das aber nachträglich ändern.
thx! 
ich hatte nicht gewusst, dass ich gruppen mit passwörtern schützen kann (asche auf mein haupt).
wenn ich per gpasswd www-data ein passwort setze, dann ein new-grp www-data funktionierts. die gids werden wohl hartkodiert im prozess gespeichert, denn newgrp erzeugt eine neue shell,
in der dann die neue gruppe gültig ist. d.h. es löst nicht das endgültige problem,
dass der oberste kdeinit hartkodierte gids trägt.
wäre natürlich ne feine sache, wenn die gids per /proc interface änderbar wären …
Was noch viel witziger ist und mir bis vor kurzem auch verborgen blieb (Asche über mein Haupt), ist die Tatsache, dass man bei Linux sogar einzelnen Benutzern oder mehreren Gruppen verschiedene Rechte auf eine Datei/Verzeichnis geben kann …
Der magische Befehl lautet setfacl und getfacl … sehr beeindruckend.
Man lernt halt doch nie aus und es gibt da noch tausende andere Befehle, die ich noch nie gesehen habe g
Ja gut, ACLs halt
die sind aber nicht-standard. somit gehen die auch nicht mit allen dateisystemen. ext2/3 hat eine acl erweiterung, XFS hat sie standardmäßig aber reiser z.b. gar nicht.
ext3 kann ACL? Auch mit einem 2.4er Kernel? Was muss ich dafür tun? Und wie läuft das dann so im Allgemeinen? Einfach die Rechte mit {s,g}etfacl zuweisen und alle halten sich dran? Sieht die rwx-Maske dann für jeden anders aus? (Bitte meine Signatur diesmal ignorieren, bin zu faul zum googeln.)
Für aktuelle 2.4er Kernel gibt es Patches (s. u.). Im Kernel 2.6 ist der Support integriert (entspr. Optionen zu den Dateisystemen).
Wie weit die Integration geht, weiss ich nicht. Also ob die ACLs nur verarbeitet werden (ja, einfach die Rechte mit den ACL userspacetools zuweisen) oder auch die Rechte entsprechend angezeigt werden.
Ob das so nicht-standard ist, weiß ich nicht … mein getfacl trägt jedenfalls das Datum “May 2000” … Und funktioniert auch mit Kernel 2.4 … jedenfalls dem Suse 2.4.21-er
Allerdings weder auf ext3, noch auf reiserfs-partitionen …
ist es nicht, aktuell nicht genauso wie 2000 die suse kernel sind gepatcht.
und wieso geht es mit ext3 nicht?
hmm, also beim kernel 2.6.2 backen konnte ich ext3 extended attributes auswählen.
cool: 8)
lechz
ja, daran ist nix neues. leider ist es etwas lahm…