kdesu nicht ohne Passworteingabe möglich?

[markp1972]

Hallo,

ich habe ein kde-Programm (vmware), welches ich nicht mit sudo laufen lassen kann. Nach Eingabe von sudo /usr/bin/vmware erscheint nur der Cursor, vom Programm ist nichts zu sehen.

Mit kdesu läuft das Programm wunderbar. Allerdings muss ich dann das root-Passwort eingeben - und genau das wollte ich mir sparen. Gibt es einen Weg (ohne allen alle Berechtigungen zu geben), um auch ein kde-Programm ohne Passworteingabe aus root starten zu können?

Gruß,
Mark

PS: Ich habe opensuse 10.1

[stefan.becker]

In /etc/sudoers die Programme eintragen.

[markp1972]

Greift kdesu ebenfalls auf /etc/sudoers zu?
Allerdings: Einen Eintrag hatte ich schon:
mark localhost = NOPASSWD: /usr/bin/vmware

Ist der Eintrag falsch?

[stefan.becker]

Ich dachte eher an einen Starter auf der Oberfläche ala "sudo programmname".

[zeromancer1972]

Ich würde mal generell die Frage in den Raum stellen, warum Du vmware nur als root starten kannst. Das sollte nämlich nicht so sein.

[markp1972]

@zeromancer1972
Damit hast du recht. Das ist inzwischen in einem anderen Thread auch geklärt, vmware läuft nun auch mit normalen Benutzer.

Nun geht es mir aber ums Prinzip, für den Fall, dass ich sowas später doch mal machen muss. Ich habe eine KDE-Anwendung, die sich von der Shell aus mit sudo programmname nicht starten lässt, ich bekomme keine Anzeige. Von der Shell aus mit kdesu muss ich ein Kennwort eingeben.

@stefan.becker
Was ist ein "Starter auf der Oberfläche"? Das Programm befindet sich unter "/usr/bin/vmware", wie würde der Starter dann aussehen?

[Rain_maker]

Rechtsklick auf einen leeren Platz des Desktops.

"Neu Erstellen" => "Verknüpfung zu Programm" ... der Rest ist selbsterklärend.


Greetz,

RM

[markp1972]

Habe ich gemacht. Bei "Programm" habe ich sudo /usr/bin/vmware eingetragen. Aber leider erscheint das Programm nicht. Auch mit ps -A | grep vm* kann ich nicht sehen, dass das Programm laufen würde. Geht das vielleicht nicht, weil sudo kommandozeilen basiert ist und nicht in der KDE läuft?

[stefan.becker]

Starte das bitte erstmal in der Kommandozeile, um zu sehen, ob das richtig eingerichtet ist.

=> Ausgaben posten

=> Datei /etc/sudoers posten

[markp1972]

Ok, hier erstmal die Datei sudoers:


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

# Host alias specification

# User alias specification

# Cmnd alias specification

# Defaults specification

# prevent environment variables from influencing programs in an
# unexpected or harmful way (CVE-2005-2959, CVE-2005-4158,
# CVE-2006-0151)
Defaults always_set_home
Defaults env_reset

# In the default (unconfigured) configuration, sudo asks for the root password.
# This allows use of an ordinary user account for administration of a freshly
# installed system. When configuring sudo, delete the two
# following lines:
Defaults targetpw # ask for the password of the target user i.e. root
ALL ALL=(ALL) ALL # WARNING! Only use this together with 'Defaults targetpw'!

# Runas alias specification

# User privilege specification
root ALL=(ALL) ALL

# Uncomment to allow people in group wheel to run all commands
# %wheel ALL=(ALL) ALL

# Same thing without a password
# %wheel ALL=(ALL) NOPASSWD: ALL

# Samples
# %users ALL=/sbin/mount /cdrom,/sbin/umount /cdrom
# %users localhost=/sbin/shutdown -h now

mark localhost = NOPASSWD: /usr/bin/vmware

Und hier der Aufruf:

mark@athlon:~> sudo /usr/bin/vmware
root's password:

Es erscheint nichts auf dem Bildschirm, soll heißen, das Programm wird nicht gestartet. Hier noch die Ausgabe von ps:

athlon:/etc # ps -A | grep vm*
3487 ? 00:00:00 vmware-serverd

:confused:

sudo und ich scheinen nicht kompatibel zu sein.

[stefan.becker]

Änder den Eintrag mal so ab:


mark ALL=NOPASSWD:/usr/bin/vmware

[Columbo0815]

Alternativ kann man für Benutzer, die Mitglied der Gruppe "wheel" sind, den Wechsel per su oder kdesu auf root wie folgt ohne Passworteingabe ermöglichen:


auth sufficient pam_wheel.so trust
in /etc/pam.d/su eintragen und nachdem der User der Gruppe wheel angehört, funktioniert das ohne Passworteingabe.

Vorsicht: Dieser User darf dann GENERELL ohne Passworteingabe fungieren. Schäden die entstehen hat sich also jeder selbst zuzuschreiben.

[markp1972]

Also mit dem Eintrag

mark ALL=NOPASSWD: /usr/bin/vmware

habe ich nun folgende Ausgabe:

mark@athlon:~> sudo /usr/bin/vmware
mark@athlon:~>

Mit anderen Worten: Ich muss kein Passwort mehr eingeben. Allerdings bleibt das Problem, dass das Programm nicht startet (oder ich das zumindest nicht sehe).

Dies wird aber nicht mehr an der sudoers liegen, oder?

@Columbo0815
Danke für den Tipp. Nun klappt es aber auch mit gezielter Rechtefreigabe, dass zumindest das root-Passwort nicht mehr abgefragt wird. Dieser Weg ist mir natürlich lieber.

Aber es bleibt die Frage: Wieso startet das Programm nicht bzw. warum wird es nicht grafisch angezeigt?

[stefan.becker]

Start vmware denn als User korrekt?

Startet VMWARE als root (also ohne sudo) korrekt?

[markp1972]

Ja,

/usr/bin/vmware
geht mit dem User mark und dem root (den ich mit "su -" oder auch "su" starte).

Auch

kdesu /usr/bin/vmware
geht mit beiden Usern.

:confused:

[medhefgo]

Das Problem ist vermutlich, dass sudo die Umgebungsvariablen zurücksetzt. Füge doch mal folgendes in die /etc/sudoers ein:

Defaults env_keep=DISPLAY

[markp1972]

Könnte sein, dass es damit zusammenhängt. Ich bekomme nämlich nun:

mark@athlon:~> sudo /usr/bin/vmware
Xlib: connection to ":0.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
Xlib: connection to ":0.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key

Kannst dir meine Frage denken: Wie gehe ich jetzt damit um?

[Columbo0815]

Der X-Server läuft als User. Aus Sicherheitsgründen kann nur genau dieser User auf diesem X-Server Programme starten. Mit dem Programm xhost kannst du das beeinflussen.

Teste mal
xhost + als dieser User. Danach darf auch root Programme auf dem X-Server anzeigen.

[markp1972]

Ich hatte zuvor mal

xhost +localhost
probiert, damit ging es nicht.

Aber mit

xhost +
klappte es!!!

Vielen Dank! Jetzt ist mir die Geschichte mit sudo doch recht klar geworden.

Gruß,
Mark

PS: EDIT: Der 2. Code-Block enthielt +localhost, statt nur +

[stefan.becker]

Äh??????????

[markp1972]

Ja, klappt nun. Hast du gelesen, dass ich noch in die Datei sudoers folgenden Eintrag hinzugefügt habe:

Defaults env_keep=DISPLAY

Danach wurde dann xhost + notwendig. Ich glaube, ich habe den Bemerkungen der Poster hier folgen können.

Was wundert dich denn dran?
EDIT: Hattest du dich wegen den 2 identischen Code-Blöcken gewundert? Ist mir gerade aufgefallen, habe ich angepasst.

[stefan.becker]

Du schreibst, dass es mit dem gleichen Befehl nicht und doch geht :)

[markp1972]

Stimmt, war ein Schreibfehler. Allerdings wie schon gefragt: Wieso geht xhost +, aber nicht xhost +localhost?

[Columbo0815]

Das war jetzt nur ein "Workaround". Sauber gelöst finde ich das nicht. So funktioniert es, ist aber nicht gerade schön.

Nur darum kannst du dich ja kümmern wenn du mehr in der Materie bist. ;)

[markp1972]

... und damit ich etwas mehr in die Materie komme: :D
Was ist der Unterschied zwischen xhost + und xhost +localhost?

Ich will mal spekulieren:
Mit xhost + darf jeder User von jedem Client aus auf meinen X-Server zugreifen.
Mit xhost +localhost kann jeder User nur von meinem Client auf meinen X-Server zugreifen.

Habe ich das richtig verstanden?

[syn]

Hi, hab den thread nur überflogen, aber ich hab das ganze so gelöst:


Als User der Zugriff auf X hat:


xauth extract /pfad/key $DISPLAY


Als User der Zugrifft auf X haben soll:


DISPLAY=:0.0; export DISPLAY
xauth merge /pfad/key


xhost sollte man wohl eher nicht mehr verwenden.

Gruß

[markp1972]

Hallo,

danke für die Antwort. Allerdings zur Vollständigkeit nochmal 2 Fragen.
1. Stimmt folgendes:
Mit xhost + darf jeder User von jedem Client aus auf meinen X-Server zugreifen.
Mit xhost +localhost kann jeder User nur von meinem Client auf meinen X-Server zugreifen.

2. Wie kann ich denn die jetzt gesetzten xhost-Einstellungen löschen?
3. Wieso ist xauth besser?

Gruß,
Mark

[syn]

Hi.

Die folgende Website beschreibt das teilweise ganz gut:
http://www.theparallax.com/dcoul/user2root/xhost.shtml

Willst du einem User wieder verbieten Fenster auf deinem Desktop zu zeichnen, reicht ein: (wohlgemerkt als der User, dem das ganze verboten werden soll)



xauth remove :0.0


Grüße.