Einen neuen User über die Systemverwaltung einrichten

[rhHeini]

Ich will meiner Frau einen Account auf meinem Squeeze einrichten, damit sie den PC auch nutzen kann.

Wenn ich über Systemverwaltung - Benutzer und Gruppen - Hinzufügen versuche das zu tun, kommt eine PW-Abfrage. Egal was ich eingebe (root, Schlüsselbund, eigenes PW), ich komme nicht weiter. Ich kriege immer ein Fenster mit: "Sie haben keine Berechtigung, die Systemkonfiguration zu ändern."

Ist das ein Bug oder gibt es da noch einen Trick drum rum?

Mfg rh

[schwedenmann]

Hallo

Und warum machst du sowas nicht per Root im terminal ?

mfg
schwedenmann

[Radfahrer]

Gefragt ist das root-Passwort.
Sicher, dass es richtig ist? Vielleicht CAPS-LOCK gedrückt?

Kannst du mit dem Passwort in einem Terminal mittels su root werden?

@schwedenmann
Die Frage war ja nicht, wie so etwas im Terminal geht, sondern über die grafische Benutzerverwaltung. Und das muss ja auch gehen, dafür ist sie ja da.

[rhHeini]

Weil ich als ehemaliger Windoser es so gewohnt bin, und ich das auf Linux jetzt zum ersten Mal brauche.

Mfg rh

[kupe]

ach komm, ein vollständig geführtes

Code: Alles auswählen

# adduser $username

wird dich schon nicht umbringen…

[TRex]

ach komm, ein vollständig geführtes

Code: Alles auswählen

# adduser $username

wird dich schon nicht umbringen…

Ungeachtet dessen, dass das vermutlich einfacher ist, sollte die grafische Verwaltung auch funktionieren. Ich stimme diesbezüglich dem Radfahrer zu und verweise nochmal auf das "richtige" Passwort.

[rhHeini]

Also ich habs dann über die Konsole gemacht.

Ändert nichts dran, graphisch gehts nicht. Meine Passwörter hab ich sicher richtig eingegeben.

Mfg rh

[Cae]

Idee: Was macht gksu(do), also das sudo-Aequivalent, wenn $USER nicht in der sudoers steht? Gar nix? "Geht nix"? su-Verhalten?

Gruss Cae

[pferdefreund]

Eventuell im Passwort Sonderzeichen, die sich dann zwischen Konsole und grafischer Oberfläche unterscheiden. Das hatte ich mal bei einer unglücklichen Fonts- und Console-Konfiguration. Das ä war dann versaut und ein @ nicht eingebbar (auf der Konsole).
Nach korrekter Rekonfiguration (weiß jetzt gar nicht mehr, was da falsch war) funktionierte alles perfekt. Sonderzeichen, insbesondere ß, Umlaute usw können da einem schon mal ans Bein pinkeln.

[frox]

KDE? Da kam ich auch nicht in den Systemadministrationsmodus, wenn ich´s nicht über kdesu aufgerufen habe.

Also Alt+F2 >

Code: Alles auswählen

kdesu kuser

Ergänzung: Bei "Systemeinstellungen" oder "Systemverwaltung", also

Code: Alles auswählen

systemsettings

(ohne Bindestrich !), hing es, glaube ich mich zu erinnern, auch schonmal.

Evtl. via Rechtsklick auf das KMenue > Menü einrichten das "kdesu" direkt mit in den Befehl einbauen, falls man es öfter braucht. So hatte ich das damals gelöst.

[Methusalix]

Hallo,

Idee: Was macht gksu(do), also das sudo-Aequivalent, wenn $USER nicht in der sudoers steht? Gar nix? "Geht nix"? su-Verhalten?

Ich beteilige mich mal an der Idee. Su hat ein ausgeprägtes Log-Verhalten, gerade auch was Nutzer angeht, die auf privilegierte Befehle zugreifen wollen - also in sudoers legitimiert sein müssen. Ich kann mir nicht vorstellen, daß dieses Verhalten durch gksu ausgehebelt werden kann, weil dann ein grundlegendes Element des Programms selber ausgehebelt wäre.
Insofern stellt sich noch mal die Frage nach Einträgen im Syslog (ergänzend zu dem, was im Eingangspost steht).

Gruß M.

[uname]

Ist bei Gnome "gksudo" standardmäßig installiert? Das glaube ich nicht, wir sind hier ja nicht bei Ubuntu. Es wird "gksu" sein und erwartet wird dann natürlich das root-Passwort. Aber auch dort lohnt es sich vielleicht mal in /var/log/auth.log nachzuschauen Kann ich jedoch nicht nachstellen, da ich kein Gnome (mehr) nutze.

[rhHeini]

Interessante Diskussion hier, interessante Hinweise.

Ja, ich benutze Gnome. Sonderzeichen kann ich ausschliessen, an anderer Stelle geht mein PW. Habs so oft probiert....

Im Syslog steht nichts dazu drin, aber im auth.log (gerade noch mal probiert):

Code: Alles auswählen

Feb 20 21:01:33 rh020 polkit-agent-helper-1[17261]: pam_unix(polkit-1:auth): authentication failure; logname= uid=1000 euid=0 tty= ruser=rolf rhost=  user=rolf

Siehe da er will mich selbst anmelden, und nicht root wie ich bei dieser Funktion vermutete hätte. Also noch mal mein eigenes PW probiert, und diesmal geht es! Ich bin drin und hab gleich mal noch einen User eingetragen. Muss mich da wohl am Sonntag verhäckt haben.

Das ist aber inkonsistent mit den Passwörtern. Hier root, da user (implizites sudo?).....

Mfg rh

[uname]

Mit der geposteten Logzeile hast du nur deinen Benutzer authentisiert und dessen Identität angenommen. Administrative Tätigkeiten kannst du damit nicht durchgeführt haben. Da sudo standardmäßig bei Debian nich genutzt wird kann ich auch nicht glauben, dass es selbst bei einer entsprechenden Berechtigung in /etc/sudoers hätte automatisch Anwendung gefunden. Gibt es spätere Einträge in /var/log/auth.log?

[rhHeini]

Das ist der ganze Block:

Code: Alles auswählen

Feb 20 21:01:33 rh020 polkit-agent-helper-1[17261]: pam_unix(polkit-1:auth): authentication failure; logname= uid=1000 euid=0 tty= ruser=rolf rhost=  user=rolf
Feb 20 21:02:04 rh020 polkit-agent-helper-1[17264]: pam_unix(polkit-1:auth): authentication failure; logname= uid=1000 euid=0 tty= ruser=rolf rhost=  user=rolf
Feb 20 21:02:14 rh020 polkitd(authority=local): Operator of unix-session:/org/freedesktop/ConsoleKit/Session4 successfully authenticated as unix-user:rolf to gain TEMPORARY authorization for action org.freedesktop.systemtoolsbackends.set for system-bus-name::1.79 [users-admin] (owned by unix-user:rolf)
Feb 20 21:03:49 rh020 chpasswd[17340]: pam_unix(chpasswd:chauthtok): new password not acceptable

Danach geht es mit dem loggen der Änderungen los. Deswegen verstehe ich das auch nicht so richtig.

Mfg rh