[gelöst] YaST Online Update als normaler Benutzer ausführen

Anonymous · 29 Juli 2013

Hallo zusammen,

ich stehe ebenfalls vor den Problem, dass apper unter KDE4 bei Updates manchmal die Abhängigkeiten nicht auslösen kann.
Jetzt möchte ich dem normalen Benutzer erlauben YaST Online Update auszuführen.

Mit kdesu zwar kein Problem, aber dann wird das root-Passwort verlangt.

Also habe ich /etc/sudoers per visudo abgeändert:

Code:

Cmnd_Alias      YASTONLINEUPDATE = /sbin/yast2 --qt online_update
benutzer ALL=NOPASSWD: YASTONLINEUPDATE

Jetzt klappt das auch mit dem User benutzer, aber beim Starten meckert YaST, dass Online Update als root ausgeführt werden muss.

Nun ist meine Frage, ob man diese Fehlermeldung ignorieren darf oder ob da noch Tochterprozesse gestartet werden, die dann als normaler Benutzer ablaufen und dadurch das Update nur unvollständig abliefe.

Bisher habe ich mich per ssh (=Fernwartung) und zypper refresh, zypper patch und zypper update beholfen.
Nun gut: In der Regel klappt es LOKAL mit den Updates und apper schon, aber wenn's mal wieder klemmt, wäre YaST Online Update im Benutzermodus eine elegante Lösung.

Kann mir jemand bitte weiterhelfen?

Ganymed · 29 Juli 2013

Hi,
ob das geht, würde mich auch interessieren. :erschreckt:

Aber ich glaube, wenn das wirklich gehen sollte, ist das er erste Schritt zum Aushebeln des Sicherheitskonzeptes der unixoiden Betriebssysteme. :???: :schockiert:

Ich hoffe jetzt kommen Fachleute ...

Gruß Ganymed

josef-wien · 29 Juli 2013

Warum soll etwas "ausgehebelt" werden, wenn root bewußt bestimmte Befugnisse an andere Benutzer erteilt? Dazu gibt es schließlich ein relativ umfangreiches Berechtigungs-Repertoire.

Aber natürlich kochen manche Entwickler ihre eigenen Suppen. So auf die Schnelle habe ich über 20 YaST-Module gefunden, in denen "hart kodiert" auf root abgefragt wird. Es ist einfacher, den Benutzer mit

/usr/share/YaST2/modules/Confirm.ycp schrieb:

Code:

    /* Message in a continue/cancel popup */
    string pop = _("This module must be run as root.
If you continue now, the module may not function properly.
For example, some settings can be read improperly
and it is unlikely that settings can be written.\n");

abzuspeisen. Ich fürchte, Deine Frage wirst Du nur durch "Versuch und Irrtum" oder über die Entwickler beantworten können. In Deinem Fall könnte zypper die bessere Wahl sein.

Anonymous · 30 Juli 2013

Vielen Dank, ich habe mir das mit YaST schon gedacht!
Kann man denn einem normalen Benutzer erlauben zypper refresh, patch & update zu starten, oder wäre die Lösung genauso komplex wie bei YaST?

Ich habe übrigens bei mir ein ähnliches Problem mit gpk-update-viewer:
Er zeigt die Updates an, ermittelt noch die zu ändernden Pakete und hängt dann fest. ( 1 CPU geht auf 100% ).
gpk-update-viewer hängt sich offenbar aber nicht komplett auf, denn er lässt sich über den [Beenden] Button beenden.

Eine dritte Frage habe ich noch: kdesu kann zwar das root-Passwort speichern, vergisst es aber nach kurzer Zeit wieder. Kann man das Passwort auch dauerhaft speichern lassen?
Es genügt der feste Aufruf von: kdesu /sbin/yast2 --qt online_update

Ich würde meinem Vater ja das root-Passwort auf einen Zettel schreiben und dann an den Monitor kleben, da aber die Enkelkinder auch an dem Rechner sitzen (dürfen), ist das keine so gute Idee.

Jägerschlürfer · 30 Juli 2013

xirtsch schrieb:
Ich würde meinem Vater ja das root-Passwort auf einen Zettel schreiben und dann an den Monitor kleben, da aber die Enkelkinder auch an dem Rechner sitzen (dürfen), ist das keine so gute Idee.

wieso gibts du deinem Vater nicht einfach das Passwort und er bewahrt es an einem sicheren Ort auf, wo nur er Zugriff hat? Sollte doch nicht so schlimm sein.

Anonymous · 30 Juli 2013

Sollte doch nicht so schlimm sein.

Naja, sichere Orte mit div. wichtigen Passwörtern hat mein Vater schon zur Genüge.
Die Sache würde für ihn nicht einfacher, weil er dann erst den richtigen Zettel finden muss, mich nebenbei sowieso anruft, eben weil er ihn nicht findet, und überhaupt: welches ist das richtige Passwort? etc.

Ab einem gewissen Alter lässt das Kurzzeitgedächnis nach, bei weiterhin tadellos funktionierendem Langzeitgedächtnis.
Ein Problem, dass uns alle mehr oder weniger bzw. früher oder später heimsuchen wird. :roll:

Die Betreuung der beiden Rechner bei ihm ist sowieso meine Aufgabe und das Problem ist ja "nur", dass apper manchmal nicht durchläuft. Also liegt es nahe, eine halbwegs benutzerfreundliche Lösung ohne Passwörter bereitzustellen.

RME · 30 Juli 2013

Hallo,

Code:
Also habe ich /etc/sudoers per visudo abgeändert:

Code:

Cmnd_Alias YASTONLINEUPDATE = /sbin/yast2 --qt online_update benutzer ALL=NOPASSWD: YASTONLINEUPDATE

Jetzt klappt das auch mit dem User benutzer, aber beim Starten meckert YaST, dass Online Update als root ausgeführt werden muss.

...also ich gehe davon aus dass Du "benutzer" auch irgendwo definiert hast; dann sollte das auch funktionieren mit:

Code:

kdesu YASTONLINEUPDATE

(evtl. 'kdesu' vergessen?)

Gruss,
Roland

Anonymous · 30 Juli 2013

kdesu ist ein su für KDE.

Wenn du kdesu eintippst, wirst du nach dem root-Passwort gefragt.

Einträge in /etc/sudoers haben nichts mit su, kdesu, xdg-su, usw. zu tun.

---

benutzer ist in meinem Fall UID 1000 - das ist derjenige, der unter /home/benutzer zu Hause ist - nichts anderes.

RME · 30 Juli 2013

kdesu ist ein su für KDE.

Wenn du kdesu eintippst, wirst du nach dem root-Passwort gefragt.

Einträge in /etc/sudoers haben nichts mit su, kdesu, xdg-su, usw. zu tun.

...stimmt nicht.

Ich habe das bei mir getestet (allerdings habe ich 'sudoers' etwas anders programmiert, aber Deine Version sollte auch tun) und es hat funktioniert.

-/-

Anonymous · 30 Juli 2013

Na dann gibt mir mal deine Version!

...stimmt nicht.

Da wäre ich für eine kurze Erläuterung sehr dankbar, ich möchte schließlich was dazulernen.

RME · 1 Aug. 2013

Hallo,

xirtsch schrieb:
Na dann gibt mir mal deine Version!

Ich möchte das Thema (meinerseits) noch abschliessen; etwas wesentliches kann ich nicht beitragen:

Der relevante Teil von meiner (experimentellen) 'sudoers' Datei:

Code:

...
# Runas alias specification

# User privilege specification
root ALL=(ALL) ALL
user0 ALL = NOPASSWD: /usr/bin/zypper ref, /usr/bin/zypper up, \
                      /sbin/yast2 online_update, \
                      /home/user0/do_update

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

'user0' ist hier der Username (Ausgabe von "echo $USER") und müsste angepasst werden.

Code:

sudo zypper up

...funktioniert (ohne Passwort Abfrage).

Code:

sudo /sbin/yast2 online_update

...funktioniert ... aber leider nur im Text-Modus.

Um das "viele" eintippen zu reduzieren, kann der Befehl natürlich auch in ein Script ausgelagert werden:

Code:

> cat /home/user0/do_update
#!/bin/bash

/sbin/yast2 online_update

# --- end of script ---

>

Code:

sudo /home/user0/do_update

..funktioniert dann auch (Text Modus). Natürlich kann der Pfad weggelassen werden ("sudo do_update") wenn das Script an einem 'normalen' Ort installiert wäre.

Das Problem: es ist schwierig irgend eine GUI als root (ohne Passwort) auszuführen. Dazu wäre im KDE eigentlich 'kdesu' der Kandidat. Leider ist diese Anwendung (wohl absichtlich) nicht 'sudo' konform; heisst 'kdesu' ist von 'sudoers' nicht betroffen. So wie 'kdesu' programmiert ist funktioniert es nicht ohne weiteres mit 'sudo' bzw. 'sudoers'. Gleiches gilt z.B. auch für 'xdg-su' womit 'YaST' gestartet wird ('xdg-su' verwendet 'kdesu').

Der 'dolphin' File Manager wird im "Super User Modus" via 'dbus-launch' gestartet, aber auch dies kann nicht einfach so in 'sudoers' eingebaut werden.

Das heisst aber nicht dass es unmöglich ist. Ich habe einiges experimentiert aber bin nun am Ende meines Lateins.

'kdesu' ist eine binäre Datei (siehe "file /usr/lib/kde4/libexec/kdesu"), also kein Script. Um zu sehen was da genau gemacht wird müsste die Source von KDE abgesucht werden.

Etwas weniges an Info kann im "The KDE su handbook" entnommen werden (im 'konqueror' als Adresse "help:/kdesu" eingegeben): interessant sind X authentication sowie Interface to su.

Ich habe versucht das user graphische 'Environment' für root zugänglich zu machen, auch mit dieser 'X cookies' Methode von 'kdesu', hatte aber nur teilweisen Erfolg.

Zum Beispiel, das Script:

Code:

#!/bin/sh

su - -c "exec env DISPLAY='$DISPLAY' \
                  XAUTHORITY='${XAUTHORITY-$HOME/.Xauthority}' \
                  $SHELL -c '/sbin/yast2 online_update'"
# -/-

startet (mit Passwort Abfrage) YaST online_update im Grafik-Modus:

Code:

./yast_update

Ich habe versucht einen ähnlichen Code für 'sudo' bzw. 'sudoers' anzupassen; die Passwort Abfrage kann verhindert werden aber entweder bekam ich eine Fehlermeldung oder YaST startete im Text-Modus. Ich denke es wäre machbar mit etwas mehr Wissen als ich das habe.

Es gibt einige relevante Beiträge im Internet, aber Lösungen habe ich keine gefunden. Es wäre sicher kein Problem für die 'kdesu' Entwickler die 'sudoers' Verträglichkeit zu verwirklichen, aber die (oder der) wollen das nicht (habe dies irgendwo gelesen; den Link habe ich nicht mehr).

Gruss,
Roland

Anonymous · 2 Aug. 2013

Hallo Roland, top Antwort!
Ich freue mich immer, wenn ich was dazulernen kann. Was mir noch fehlt, wären 5-6 gute Linux-Bücher.

Aber selbst dann, könnte ich mich vermutlich tagelang mit Nachschlagen beschäftigen, ohne eine Lösung "auf Anhieb" zu finden.

YaST im Textmodus möchte ich meinem Vater nicht zumuten.

Ich denke mal, ein Shell-Script, das zypper refresh, zypper patch und zypper update selbstständig nacheinander aufruft, am besten noch ohne die (yes) Abfrage, wäre das Einfachste.

Ist sowas einfach zu schreiben? Könntest du mir da evtl. helfen?
/etc/sodoers zu editieren ist ja kein Problem für mich.

P.S. Ein herzliches Dankeschön an alle auch von meinem Vater.

RME · 2 Aug. 2013

YaST im Textmodus möchte ich meinem Vater nicht zumuten.

...sehe ich auch eher als Notfall (wenn Grafik nicht mehr funzt).

Ich denke mal, ein Shell-Script, das zypper refresh, zypper patch und zypper update selbstständig nacheinander aufruft, am besten noch ohne die (yes) Abfrage, wäre das Einfachste.

Etwa so:

Code:

#!/bin/bash

OPTIONS="--non-interactive --no-gpg-checks --quiet --auto-agree-with-licenses"

echo
echo "------------------------------------"
echo "$(date)"
echo

echo "--- zypper ref ---"
/usr/bin/zypper $OPTIONS ref
echo "(fertig)"
echo

echo "--- zypper patch ---"
/usr/bin/zypper $OPTIONS patch
echo "(fertig)"
echo

echo "--- zypper up ---"
/usr/bin/zypper $OPTIONS up
echo "(fertig)"
echo
echo "------------------------------------"

# -/-

Refs: SDB:Zypper usage 12.2
>>> https://en.opensuse.org/SDB:Zypper_usage_12.2
(und/oder die "man pages" für 'zypper')

Nenne das Script z.B. "my_update"

In ein Verzeichnis kopieren wo es vom System gefunden wird (siehe Ausgabe von "echo $PATH").

Vorschlag:

Code:

sudo cp my_update /usr/local/bin/
sudo chmod 755 /usr/local/bin/my_update

Zum testen entferne "--quiet" in den OPTIONS

dann:

Code:

sudo my_update

Um die Passwortabfrage zu verhindern, in der 'sudoers' Datei:

Code:

...
# Runas alias specification

# User privilege specification
root ALL=(ALL) ALL
user0 ALL = NOPASSWD: /usr/local/bin/my_update

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

('user0' entsprechend anpassen)

Gruss,
Roland

Anonymous · 2 Aug. 2013

Danke!

[gelöst] YaST Online Update als normaler Benutzer ausführen

Anonymous

Gast

Ganymed

Guru

josef-wien

Ultimate Guru

Anonymous

Gast

Jägerschlürfer

Moderator

Anonymous

Gast

RME

Advanced Hacker

Anonymous

Gast

RME

Advanced Hacker

Anonymous

Gast

RME

Advanced Hacker

Anonymous

Gast

RME

Advanced Hacker

Anonymous

Gast