User <-> Gruppenverwaltung

[mrhatch]

Hallihallo,

da ich ja unter Slackware als User Probleme habe, einige Programme auszuführen, diese aber als root problemlos starten kann, beschäftige ich mich gerade mit der User-/Gruppenverwaltung.

Unter SuSE, Mandrake und Konsorten wird während des Setups bei der Einrichtung eines Arbeitsusers schon gefragt, welchen zusätzlichen Gruppen - außer users - der Benutzer hinzugefügt werden soll.

Jetzt befinden sich meiner /etc/group folgende Gruppen:

root::0:root
bin::1:root,bin,daemon
daemon::2:root,bin,daemon
sys::3:root,bin,adm
adm::4:root,adm,daemon
tty::5:
disk::6:root,adm
lp::7:lp
mem::8:
kmem::9:
wheel::10:root
floppy::11:root
mail::12:mail
news::13:news
uucp::14:uucp
man::15:
games::20:
slocate::21:
utmp::22:
smmsp::25:smmsp
mysql::27:
rpc::32:
sshd::33:sshd
gdm::42:
shadow::43:
ftp::50:
pop::90:pop
nobody::98:nobody
nogroup::99:
users::100:
console::101:

Zunächst einmal, welcher Sinn ergibt sich z.B. aus der Gruppe "games" oder "gdm", und wie kann ich Aufschluß darauf bekommen, welchen Gruppen ein User standardmässig zugeordnet sein muss, um einen einwandfreien Betrieb gewährleisten zu können.

Ich habe schon die entsprechenden Kapitel aus "Linux - Wegweiser zur Installation und Konfiguration" gelesen, aber so richtig schlau werde ich daraus nicht.

 

[Aracon]

Also da kannst du für dich anpassen wie du es haben willst, wenn ein user in der games gruppe ist hat er vollen zugriff auf die Spiele usw.

Bei mir sieht das folgendermaßen aus:
wheel::10:root,aracon
audio::18:aracon
cdrom::19:aracon
games::35:aracon
cdrw::80:aracon
users::100:games,aracon

 

[mrhatch]

Okay, soweit habe ich mir das schon gedacht.
Aber wo hört der Spaß denn dann auf. Will sagen, ab wann wird es gefährlich, einen User mit Rechten auszustatten? Wenn ich jetzt als "user" arbeite, und feststelle, dass mir z.B. die Berechtigung fehlt, den Brenner zu nutzen (s. mein Problem mit k3b), dann könnte ich ja der Versuchung erliegen, dem user dieses Recht blindlings durch Zuordnung zur entsprechenden Gruppe zu verpassen, und irgendwann dard der user so viel wie root, und alle Sicherheitsaspekte sind für die Katz.

Ich male das jetzt so schwarz, weil ich neben wissbegierig halt manchmal auch ein wenig faul bin.

 

[Aracon]

Die Gruppen haben ihre bestimmeten rechte. Z.b. Systemordner gehören zu grupp "root" und da hat kein user dran was zu machen, auch wenn er in noch so ner tollen Gruppe ist.
Du solltest die trennung zwischen root und user auf jedenfall strickt beibehalten.

 

[chb]

Dein Benutzer braucht nur Mitglied der Gruppe users zu sein, dann gehts

Aber gib mir mal folgende Daten, wär doch schlimm wenn des mit K3b net lösbar wär..

ls -la /dev/hdX -> wobei X der Brenner iss

/etc/fstab -> die Zeile vom Brenner

ls -la /usr/bin/cdrecord ( oder wo cdrecord halt liegt )

 

[mrhatch]

ls -la /dev/hdX -> wobei X der Brenner iss
lrwxrwxrwx 1 root root 8 Feb 6 02:08 /dev/cdrom -> /dev/sr0


etc/fstab:
/dev/cdrom /mnt/cdrom auto user,codepage=850,ro,noauto,exec,iocharset=iso8859-15 0 0

ls -la /usr/bin/cdrecord:
-rwxr-xr-x 1 root bin 279324 Aug 18 02:38 /usr/bin/cdrecord*

 

[codc]

Für dein Problem gibt es den Befehl su (switch user in manchen Bücher auch superuser was aber falsch ist da man jeder user werden kann).

Die Gruppe wheel ist idR berechtigt bzw. dafür vorgesehen, dass die root werden können (Standarteinstellung von su). Dazu musst du in /etc/sudoer die evtl. entsprechend die Berechtigung einstellen. IdR kann man die Datei aus Sicherheitsgründen nicht mit vi editieren sonder als root "visudoer" ausführen steht aber normalerweise in der Datei selber die man mit less o.ä. lesen kann.

Also als User der Gruppe wheel an der Console su und dann Passwort von root dann hast du die root-shell. Weiteres man su

Beim Ausloggen bist du wieder User Gruppe wheel

 

[mrhatch]

Das ist schon ziemlich strange. Nachdem ich jetzt meinen Arbeitsuser neu angelegt, und ihn nur den Gruppen "users,wheel" zugeordnet habe, startet auch k3b ordnungsgemäß.
Allerdings habe ich immer noch die beiden Fehlermeldungen, dass cdrecord, sowie cdrdao nicht mit root-Rechten laufen.

 

[chb]

Sieht ja ganz gut aus :-)

mach mal als root folgendes

chgrp users /usr/bin/cdrecord
chgrp users /dev/sr0

Danach versuch mal k3b ..

Ajo welche Kernel Version hast du, oder ist das ein SCSI Brenner ?

 

[mrhatch]

Mein Kernel ist der bare.i-2.4.22 von der Slackware-CD. Da ich immer noch nicht alle Module zusammenhab, warte ich mit dem Update auf 2.6.2 noch, dafür brauche ich Zeit und Ruhe.
Nein, ein normaler IDE-Brenner ist das.

Die Fehlermeldungen bleiben.

 

[chb]

Was kommt jetzt genau für ne Fehlermeldung ?

 

[mrhatch]

cdrecord does not run with root privileges

cdrdao does not run with root privileges

Ich habe aber das chgrp users auf beide Dateien angewandt.

 

[chb]

mach mal

ls -la $(which cdrecord) bzw
ls -la $(which cdrdao)

 

[mrhatch]

Gibt mir beide Male die cdrecord bzw. cdrdao unter /usr/bin aus. Sind also nicht irgendwie doppelt vorhanden, falls du das damit rausfinden wolltest.

 

[chb]

Sorry hab mich da vertan :/ .. kannst des nochmal machen so wie oben im geänderten Posting

 

[mrhatch]

Kannst du das Posting mal kurz quoten, weil ich auf Anhieb keine Änderung sehe.

 

[chb]

ls -la $(which cdrecord)
ls -la $(which cdrdao)

 

[mrhatch]

Die Ausgabe bleibt aber die gleiche:
-rwxr-xr-x 1 root users 279324 Aug 18 02:38 /usr/bin/cdrecord*

-rwxr-xr-x 1 root users 525496 Oct 28 2002 /usr/bin/cdrdao*

 

[chb]

Hmm Ich hab sonst immer CDs unter root selber gebrannt, aber anscheinend muß man hier doch mit härteren Mitteln zuschlagen

(als root)

chmod ug+s /usr/bin/cdrecord
chmod ug+s /usr/bin/cdrdao

Damit rennt cdrecord / cdrdao als root ..

 

[mrhatch]

Danke, jetzt geht's. Kurz noch die Frage:
Was bedeutet genau das 's' in den Rechten?

-rwsr-sr-x 1 root users 525496 Oct 28 2002 cdrdao*
-rwsr-sr-x 1 root users 279324 Aug 18 02:38 cdrecord*