Greg schrieb
Aber wie soll sonst ein Neuarcher damit zu recht kommen wenn man sowas nicht lesen kann. Bei Ubuntu wird ja alles vorgekaut und da macht keiner mit Gruppen rum.
Also ich gehe ja eher davon aus, daß jemand, der sich für Archlinux entscheidet, doch schon über Gruppen ("Aufzucht und Hege" <g>) Bescheid weiß...
Als User muß mich das sowieso nicht interessieren, als Administrator (wenn's auch daheim so ist das der User auch root ist) sehr wohl...
Wenn man nicht schon sowieso über ein gewisses Linux-Allgemeinwissen verfügt wird man nach Lesen des Wikiartikels wohl auch nicht schlauer sein in dem Sinne "Soll er nun hinein in lp oder nicht???" Wenn ich nicht weiß was ich tue (bzw. nachschauen kann ob es Sinn macht) dann macht ein wildes Rumgestochere mit Gruppen auch keinen Sinn.
Wenn man sich aktuelle (filesystem-Paket)/etc/group File nimmt dann sind Gruppen doch dazu da um bestimmte Dinge zu organisieren. Das sind dann:
a) Zugriff auf Geräte (spiegelt sich im /dev Verzeichniss wieder)
b) Ausführen von bestimmten Programmen
c) Zugriff auf Verzeichnisse/Dateien im Dateisystem
Die Gruppenrechte sind nun die einzige Möglichkeit um für mehr als einen User das zu regeln/reglementieren (wenn wir others weglassen). Und User heißt ja unter Linux/Unixen erstmal nicht "du und ich, bzw. der michael", sondern jeder Prozess braucht einen "Besitzer". Deswegen geht es ja hier bei unseren Gruppen nicht zwangsläufig darum: Muß/darf Greg oder GerBra nun rein (als "User")?
Viele der o.a. Gruppen sind teils historisch gewachsen und spielen auch heutzutage nicht mehr *die* Rolle. Dinge/Vorgänge ändern sich: Die Zeiten als Benutzer noch über "dumme" Textterminals (TTYs) direkt auf einem Server/Hostsystem arbeiteten - also ohne X-Server - sind in dieser Form zum Glück vorbei; jeder, der noch mit einer 3270-TE auf dem Host rumwerkelte kann ein Lied davon singen...)
Und man muß bei sowas wie unserem Wiki aufpassen, nicht alle aus der "Warte des Desktops" sehen/erklären zu wollen. Die Server-Welt bzw. Dienste ist gerade bzgl. Gruppen viel spannender, und Linux ist nun mal ein System was vom Server/Host-Bereich mittlerweile auch beim Desktop angekommen ist. Viele Gruppen, die man so vorfindet - zumindest existent in der /e/group - kommen auch aus diesem Bereich bzw. machen "dort Sinn".
Ich hatte ja schon einiges geschrieben zu den Gruppen aus filesystem->/etc/group, wo es für "Benutzer/User wie du und ich" Sinn macht reingepackt zu werden - oder eben besser nicht...
Nochmal ein paar Dinge zu Gregs Aufzählung:
1. adm
Kann man nutzen für Admin-Aufgaben. Wird bei uns aktuell nicht genutzt (früher waren die Logfiles mal gruppenzugehörig zu adm, dafür ist ja aktuell die Gruppe log da). Das ist so eine Gruppe wo eher das Motto gilt: es ist dein Linux, mach was du willst. Wenn du Hilfsadmins hast spricht nichts dagegen diesen über die adm Gruppe Zusatzberechtigungen auf Dinge zu geben....)
2. tty
Da muß kein Benutzer rein. Diese Gruppe ist eher für Prozesse (im Sinne von USER-Id des Prozesses), die z.B. direkt auf /dev/tty* lesen/schreiben müssen. Beispiel *könnte* ein syslog-Dienst sein, der unter dem User syslog als Prozeß läuft und nun direkt auf /dev/tty12 schreiben soll. Dann würde man dem "User" syslog durch Mitgliedschaft in der Gruppe tty die Berechtigung dazu geben...
3. disk (und in diesem Sinn auch storage)
Gegeben sei z.B.:
# ls -l /dev/sda2
brw-rw---- 1 root disk 8, 2 23. Feb 23:29 /dev/sda2
User paul hat z.B. im Filesystem des eingehängten /dev/sda2 nur das Recht sagen wir /mnt/paulbilder zu lesen. Wenn paul aber Mitglied der Gruppe disk ist, dann kopiert er z.B. mit dd if=/dev/sda2 ein Image irgendwohin und mountet dieses Image in einer Umgebung in der er root-rechte(uid 0) hat. Daheim z.B. Und voila, schon kommt er auch an /mnt/chefbilder_mit_monika ran.
Oder (entweder besoffen oder mutwillig) er dreht dd um und macht ein dd if=/dev/zero of=/dev/sda2 - weil schreiben darf er ja als disk-Mitglied auch...
Das ist die Gefährlichkeit bei Zugriffe auf Devicefiles - und das eigentliche Ziel der Aktion war einfach nur dem User Paul Zugriff auf "seinen" Ordner zu geben.
Mit der storage Gruppe hatten wir (hal) eine Zeitlang genau sowas als "Notwendigkeit"- Wechselmedien wurden rw als Devicefiles mit der Gruppe storage erstellt, der User mußte da Mitglied sein um (über hal) das Device einhängen zu dürfen. Bei einer Wechselplatte z.B. die innerhalb einer Firma von verschiedenen Leuten benutzt wird (die alle gesonderte Rechte im Filesystem haben) würde/könnte das ausgehebelt werden durch den - an sich unnötigen - Zugriffsmöglichkeit aufs Device-File. (Sicher hinkt as Beispiel, es gibt bei sowas genug ander Möglichkeiten an die Datehn der Platte zu kommen). Ich will damit eher sagen: Aktuell braucht ein Benutzer kein Zugriff auf ein Devicefile für Wechselmedien mehr und das finde ich gut.
(NB: Und man sollte nicht so tun: Pah, ich bin doch mein Benutzer, da kann der Zugriff über disk/storage nicht schaden. "Liederlich" mit Rechten umzugehen sollte man sich garnicht angewöhnen: Was daheim evtl. noch "funzt" wird einem später beruflich vielleicht mal zum Verhängnis...)
4. lp
Gedruckt wird i.d.R. über Dienste wie den CUPSd (und somit müßte nur der User unter dem cupsd gestartet wird ggf. in die lp Gruppe). Ein Benutzer (du und ich) hat mit dem Devicefile /dev/parportX normalerweise nichts am Hut, zumindest nichts was die Gruppe (lp = lineprinter, wer hat noch einen Zeilendrucker<g>) suggeriert. Mittels der Gruppe lp kann ein Admin z.B. sowas wie Druckeradministratoren generieren (Lofgile-Auswertung, Druckdaemon-Wartung....)
5. mem/kmem
Suggeriert schon "irgendwas mit Speicher". Ist wohl eher für (Kernel)-entwickler nötig, bei Debug-Kernel gibt es AFAIK Module oder Devicefiles, die im weitesten Sinn "Speicherabbilder" sind... Für sowas wäre dann diese Gruppe sinnvoll (da man Entwicklern ja nicht unter jeder Umgebung root-Rechte geben will).
Vor einiger Zeit war AFAIK das Abbild des Hauptspeichers im proc-FS /proc/kcore noch root:mem. Vorstellbar wäre z.B. ein Virenscanner, der auch das Speicherabbild scannen soll. Wenn dieser Prozess nun als User avir laufen würde könntem diesem User übr die Gruppe mem/kmem Zugriff darauf gewährt werden... Also auch hier nichts für Benutzer "wie du und ich"...
6. mail, ftp, http
Auch das sind Gruppen die nicht für Benutzer gedacht sind, wohl aber um Dienste zu organisieren. Um z.B. den (System)usern unter denen der postix-MTA (dessen Prozesse) laufen Zugriff auf bestimmte Verzeichnisse geben zu können (und noch dem Virenscanner Prozeß dazu) gibt es die Grupppe mail.
Genauso erstmal http. Nicht alles von der Desktop/Heimrechner-Seite betrachten wollen ("Mein Firefox klappt doch auch ohne Mitgleidschaft in der gruppe!"). Wenn ein Webserver unter dem User apache läuft, dann muß der aktuell in die http-Gruppe da nur Gruppenmitglieder nach /srv/http/htdocs lesen/schreiben dürfen (wenn der Admin es so einrichtet mittels Gruppen). Und wenn es nun noch einen Indexer wie htdig o.ä. gibt, der muß ggf. auch in diese Gruppe damit er überhaupt an die zu indiziernden Dateien "rankommt"...
Und nein: ein FTP-Transfer für einen Benutzer geht nicht schneller, besser, schöner <g> wenn dieser Benutzer in der ftp-gruppe ist ;-)
7. nobody
User und gruppe nobody nimmt man immer für Prozesse die eigentlich "keinerlei Rechte haben" sollen, somit weitgehend unpriviligiert und ein "Niemand" auf dem System sind. Webserver werden gerne unter dem User nobody laufen lassen. Traditionsmäßig sollte man user und gruppe nobody eigentlich von allem auschließen (wo es Ausschluß-Regeln gibt).
8. dbus/hal
Der dbus-Systemdaemon-prozess läuft unter dem benutzer dbus (bei hal war es der User hal). Der dbus-Prozeß legt nun diverse "Dateien" (Files, verzeichnisse, Sockets, FIFOs,...) an - unter Linux ist bekanntlich alles eine "Datei" - die alle "Rechte" haben, also Owner:Gruppe:Others. hal und dbus interagierten nun bei verschiedenen Dingen, da Prozeß-Owner aber nur beschränkten Zugriff hatten (eben keine root-Rechte) mußte der User hal z.B. in der Gruppe dbus sein (oder umgekehrt) um über die Gruppenrechte die Möglichkeit zu haben auf bestimmte Dinge des anderen Daemons Zugriff zu haben.
Das ist ein gutes Beispiel das sich komplexe Systeme (und das ist Linux, nicht unbedingt kompliziert - aber komplex) auch in komplexeren Strukturen neiderschlagen - und das auch Dienste "User" sein können, nicht nur die Benutzer "wie du und ich"...
Aber angenommen: ich als GerBra habe ein geniales Tool was mit dbus "arbeitet". Das will ich nun laufen lassen unter meinem Usernamen. Da kann es dann notwenduig und sinnvoll sein wenn ich meinen Admin (auch mich <g>) bitte mich doch in die dbus-gruppe zu packen. Aber nur um über zig Prozess-OwnerUID-Eskalationen Thunar zu nutzen - dafür ist dbus nicht gedacht und nicht nötig...
Ich habe es deswegen (wieder mal!) sehr ausführlich gemacht um eigentlich nur hier kurz zu sagen:
Nicht jede Gruppe in /e/group ist es "wert" darauf abgeklopft zu werden: Sollen da "du und ich" rein?
Genauso falsch wäre es am Sudoko-Spiele-PC (mit Linux, klar!) zu sitzen und sich über die Jahre entstandenes, bewährtes zu belustigen, zu wundern - oder graue Haare zu kriegen. Die Linux-Welt ist (zum Glück!) größer und spannender als die evtl. 60cm zwischen Kopf und Bildschirm im OSI-Layer8-Bereich ;-))))))