Ich hatte gerade ein dickes Problem auf meiner Lucid-amd64 Installation von der alternate-CD, s. hier: 356152 betreffend update-notifier. Letzlich lief alles darauf hinaus, das der user "ingo" nicht Mitglied der Gruppe "admin" war. Das ist eigentlich auch nicht nötig, da die alternate-CD einen echten root-account einrichtet und der update-notifier ja unter dem user läuft, der ihn gestartet hat. Erst für die Durchführung des Updates werden ja admin-Rechte benötigt und abgefragt.

Ich habe zunächst den user "ingo" der Gruppe "sudo" zugefügt, aber das hat nix genützt. Erst mit Aufnahme in die Gruppe "admin" klappt es.

Debian-Squeeze z.B. kennt und nutzt die Gruppe "admin" überhaupt nicht. Deshalb meine Frage:

Wozu dient die Gruppe "admin" auf Ubuntu-Systemen, welche Rechte hat sie, wo ist das konfiguriert? Kann man irgendwie feststellen, welche Programme/Tools diese Gruppe voraussetzen?

Eigentlich ist sie ja völlig überflüssig, es gibt ja die Gruppe "sudo" für solche Dinge bereits - und die ist auch in /etc/sudoers freigeschaltet.

Viele Grüße,

Ingo

P.S.: der 356152 ist für mich jetzt nach langem Suchen zwar gelöst, aber unbefriedigend ist's doch - und ggf. ein Sicherheitsrisiko.

Eigentlich ist sie ja völlig überflüssig, es gibt ja die Gruppe "sudo" für solche Dinge bereits - und die ist auch in /etc/sudoers freigeschaltet.

Benutzer, die in der Gruppe sudo sind, dürfen jeden Befehl unter jedem Benutzerkontext ausführen.
Für Benutzer in der Gruppe admin gilt standardmäßig das gleiche (glaub ich, ich weiß grad nicht wie viel ich in meiner sudoers rumgefummelt hab), wobei man die Gruppen auch einschränken kann, indem man z.B. angibt, dass die Gruppe sudo nur cat und ls benutzen darf um Dateien und Ordner zu prüfen.

Wozu dient die Gruppe "admin" auf Ubuntu-Systemen, welche Rechte hat sie, wo ist das konfiguriert? Kann man irgendwie feststellen, welche Programme/Tools diese Gruppe voraussetzen?

In den Dateiberechtigungen ist geregelt, welcher Gruppe eine Datei oder ein Verzeichnis gehört - Gruppenmitglieder haben dann die Berechtigungen der Gruppe, der Eigentümer hat meist noch mehr Berechtigungen. So ist z.B. das Laufwerk unter /dev/sda Eigentum von root, der alles damit machen darf, und der Gruppe disk, die lesen und schreiben darf (also eigentlich auch alles).
Folglich können Benutzer, die in der Gruppe disk sind, die Partitionstabelle ändern, neue Partitionen erstellen und alte löschen.

Wenn du wissen möchtest, welche Gruppe welche Dateien im System bearbeiten darf, brauchst du lediglich folgendes ausführen:

find <pfad> -group <Gruppenname>

ingo2 schrieb:

Wozu dient die Gruppe "admin" auf Ubuntu-Systemen, welche Rechte hat sie, wo ist das konfiguriert? Kann man irgendwie feststellen, welche Programme/Tools diese Gruppe voraussetzen?

Siehe Benutzer und Gruppen. Vermutlich wurde sie aufgrund der sudo-Funktion zur Systemverwaltung durch den Benutzer eingefuehrt - ein Punkt, in dem sich Ubuntu wesentlich von anderen Linux-Distributionen unterscheidet.

aasche schrieb:

ingo2 schrieb:

Wozu dient die Gruppe "admin" auf Ubuntu-Systemen, welche Rechte hat sie, wo ist das konfiguriert? Kann man irgendwie feststellen, welche Programme/Tools diese Gruppe voraussetzen?

Siehe Benutzer und Gruppen.

Das einzige was dort steht: "# "System administrieren:" "admin" "

Das ist absolut nichtssagend, denn jeder, der root-Rechte erlangen kann (ob als root oder mit sudo) kann das System administrieren.

Mich interessiert jedoch, welche Programme/Prozeße unter dieser Gruppe laufen bzw. diese Gruppe benötigen. Genau das scheint mein Problem mit "update-notifier" gewesen zu sein. Eigentlich ist es völlig egal, wie man root-Rechte erhält, also sollte die ansonsten übliche Gruppe dafür sudo ausreichen. Warum muß hier Ubuntu ein eigenes Süppchen kochen - es sei denn die Gruppe "admin" wird noch anderweitig genutzt - und darauf zielt meine Frage.

Ansonsten hätte es ja gereicht, den primären User der Gruppe "sudo" hinzuzufügen - das geht aber dann trotzdem noch nicht, es muß offenbar "admin" sein!

Ingo

In der Standardeinstellung von Ubuntu können alle Mitglieder der Gruppe "admin" per sudo root-Rechte erlangen. Genau dafür ist die Gruppe admin da. Man könnte natürlich stattdessen jeden Nutzer extra in die sudoers-Datei eintragen. Was daran aber einfacher sein soll ist mir nicht ganz klar.ingo2 schrieb:

aasche schrieb: (...) Eigentlich ist es völlig egal, wie man root-Rechte erhält, also sollte die ansonsten übliche Gruppe dafür sudo ausreichen. Warum muß hier Ubuntu ein eigenes Süppchen kochen - es sei denn die Gruppe "admin" wird noch anderweitig genutzt - und darauf zielt meine Frage.

Es gibt standardmäßig keine Gruppe "sudo". Und admin wird genau dafür genutzt, um den sudo-Zugang zu regeln.

Nach langem Googlen habe ich noch dies gefunden. Da heißt es:

Administer the system This right is gained by adding the user to the "admin" group. Users in the "admin" group can use sudo to gain administrative privileges after supplying their password. (Ref.: /etc/sudoers) The "admin" group is configured to be the PolicyKit "administrator authentication" group. (Ref.: /etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf)

Also sollte es unter Lucid egal sein, ob man in "admin" oder "sudo" ist - ist es aber nicht!

lotharster schrieb:

Es gibt standardmäßig keine Gruppe "sudo". Und admin wird genau dafür genutzt, um den sudo-Zugang zu regeln.

Da muß ich leider widersprechen, hier die original /etc/sudoers von Lucid:

# /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the man page for details on how to write a sudoers file.
#

Defaults	env_reset

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root	ALL=(ALL) ALL

# Allow members of group sudo to execute any command after they have
# provided their password
# (Note that later entries override this, so you might need to move
# it further down)
%sudo ALL=(ALL) ALL
#
#includedir /etc/sudoers.d

und die Gruppe "sudo" existiert auch, nur ist niemand Mitglied darin:

ingo@pp:~$ cat /etc/group | grep sudo
sudo:x:27:

Ingo

keine Ahnung, was Du da für eine Installation hast oder was Du nachträglich geändert hast, jedenfalls schaut eine Original /etc/sudoers schon etwas anders aus:

bei Dir fehlt dieser Eintrag am Ende

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

ebenso ist es nicht richtig, daß bei einer Alternate-Installation ein echter Root-Account eingerichtet wird, da unterscheidet sich die Alternate-Installation überhaupt nicht von einer normalen Desktop-Installation.

Ubunux schrieb:

keine Ahnung, was Du da für eine Installation hast oder was Du nachträglich geändert hast,

Ich habe von der alternate-CD-amd64 für 10.04.1 installiert, hier zum verify die md5sum:

ingo@pp:~/data/Download$ md5sum ubuntu-10.04.1-alternate-amd64.iso 
f3da7da6931e3160738b3067d79e346a  ubuntu-10.04.1-alternate-amd64.iso

jedenfalls schaut eine Original /etc/sudoers schon etwas anders aus: bei Dir fehlt dieser Eintrag am Ende

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

Genau das habe ich manuell nachtragen müssen und den user "ingo" in die "admin group" aufnehmen müssen - Ehrenwort, das hat der Installer so gemacht!

ebenso ist es nicht richtig, daß bei einer Alternate-Installation ein echter Root-Account eingerichtet wird, da unterscheidet sich die Alternate-Installation überhaupt nicht von einer normalen Desktop-Installation.

Das konnte ich so nicht akzeptieren und habe gerade das genannte ISO in eine VM gepackt und nochmals installiert mit folgenden Einstellungen:

• F2: Sprache = Deutsch

• F3: Expertenmodus (nur so kann ich auch grub-legacy ... auswählen).

Und zum Beweis hier der Scrreenshot des Menus, bei dem ich einen echten root-account anlegen kann und auch gemacht habe: root account wählen.

Was du schreibst ist ja völlig ok, so geht es ja auch. Aber der Installer hat was anderes abgeliefert das war lange mein Problem.

Und wenn man jetzt noch hier liest:

Use sudo to administer the system

This right is gained by adding the user to the "admin" group.

Users in the "admin" group can use sudo to gain administrative privileges after supplying their password. (Ref.: /etc/sudoers)

Beginning with Ubuntu 10.04 LTS, this right can also be granted by adding the user to the "sudo" group for compatibility reasons with Debian.

Dann haben die bei Canonical zumindest in diesem Falle etliches verbockt - oder bist du anderer Meinung?

Viele Grüße, Ingo

P.S.: und bitte jetzt nicht den Debian-Installer dafür blamen - der gleiche Installer in Squeeze macht das absolut korrekt. Und Squeeze benötigt keinen zusätzlichen Eintrag für "%admin" in der sudoers und auch nicht einen User mit sudo-Privilegien. Und trotzdem funktioniert der update-notifier einwandfrei

nur noch mal zur Klarstellung: Expertenmodus ist für mich etwas anderes wie eine "normale" Installation

Ubunux schrieb:

nur noch mal zur Klarstellung: Expertenmodus ist für mich etwas anderes wie eine "normale" Installation

Warum sollte man sonst die alternate-CD überhaupt wählen ???

Und hier nochmal mein Nachtrag von oben, hast du wohl noch nicht gelesen:

P.S.:und bitte jetzt nicht den Debian-Installer dafür blamen - der gleiche Installer in Squeeze macht das absolut korrekt. Und Squeeze benötigt keinen zusätzlichen Eintrag für "%admin" in der sudoers und auch nicht einen User mit sudo-Privilegien. Und trotzdem funktioniert der update-notifier einwandfrei

Stimmt schon, bei der Experteninstallation kommt die sudo-Gruppe noch dazu. Bei maverick stehen beide in /etc/sudoers. Vielleicht ein lucid-Bug.

adun schrieb:

Vielleicht ein lucid-Bug.

Ganz sicher und ich bin da nicht allein, s. 356152, die letzten comments darin sind von mir. Nur will da keiner verantwortlich sein.

Aber das alles hilft mir nicht, mein Problem und die Lösung wirklich zu verstehen. Kann es sein, daß Ubuntu da irgendwo die Gruppe "admin" hart codiert hat?

Eigentlich sollte es doch völlig egal sein, wie man die root-Rechte erhält, ob per root-account, oder GTruppe "sudo" oder Gruppe "admin"? Ich verstehe es nicht

Viele Grüße, Ingo

ohne jetzt näheres nachgeschaut zu haben kann das durchaus mit dem aktivieren des Root-Accounts zusammenhängen, jedenfalls ohne Aktivierung des Root-Accounts schaut die /etc/sudoers genau so aus wie ich oben geschrieben habe

adun schrieb:

Stimmt schon, bei der Experteninstallation kommt die sudo-Gruppe noch dazu. Bei maverick stehen beide in /etc/sudoers. Vielleicht ein lucid-Bug.

siehe oben, bei einer frischen Lucid Alternate-Installation stehen ebenfalls beide in der /etc/sudoers

welchen konkreten Sinn zwei Gruppen da machen erschließt sich mir im Moment ebenfalls nicht

ingo2 schrieb:

P.S.:und bitte jetzt nicht den Debian-Installer dafür blamen - der gleiche Installer in Squeeze macht das absolut korrekt. Und Squeeze benötigt keinen zusätzlichen Eintrag für "%admin" in der sudoers und auch nicht einen User mit sudo-Privilegien. Und trotzdem funktioniert der update-notifier einwandfrei

zum Debian-Installer habe ich gar nichts geschrieben aber: bei Debian gibt es im Gegensatz zu Ubuntu einen voll aktivierten Root-Account ... evtl. haben die Ubuntu-Entwickler ab Lucid schlicht versäumt den Update-Notifier an das sudo-Konzept anzupassen?

Ubunux schrieb:

zum Debian-Installer habe ich gar nichts geschrieben

Das behauptet aber canonical/Ubuntu: "Probleme mit dem "alternate-installer" bitte bei Debian melden

evtl. haben die Ubuntu-Entwickler ab Lucid schlicht versäumt den Update-Notifier an das sudo-Konzept anzupassen?

Und genau das ist das Problem bei 356152 aber keiner will damit zu tun haben - obwohl das eine Sicherheislücke ist. Denn ein System ohne Benachrichtigung bei securityy-updates ist unsicher.

Ingo