staging.inyokaproject.org

Hallo,

klar wissen wir, wie das geht 😉 Geändert. Und Danke für die Änderung ☺

Gruß, noisefloor

Antiqua schrieb:

... Mit sudo passwd -l root ist kein Einloggen im Recoverymode mehr möglich! Evtl. das komplett entfernen und nur noch sudo passwd -d root im Artikel lassen?

Mit sudo passwd -d root wird bei meiner 14.04.2 Server-Frischinstallation (2-x getestet) zwar das Passwort dem Benutzer root entzogen, dafür kann man sich danach ganz OHNE Passwort in der Konsole als root anmelden. Das Passwort wird erst gar nicht abgefragt, man landet sofort mit root-Rechten in Prompt. Hat wahrscheinlich was mit Trusty Tahr zu tun.

Update: mit sudo passwd -dl root wie in CommunityHelpWiki steht, wird das o.g. Problem behoben und auch der Zugang zum root-Recovery-Modus wird nicht gesperrt (wenn ich richtig verstanden habe, worum es geht. s. Anhang).

fu-sin schrieb:

Mit sudo passwd -d root wird bei meiner 14.04.2 Server-Frischinstallation (2-x getestet) zwar das Passwort dem Benutzer root entzogen, dafür kann man sich danach ganz OHNE Passwort in der Konsole als root anmelden.

Natürlich, das ist exakt die Funktion von

sudo passwd -d

(das root ist überflüssig, schadet aber auch nicht).

Das Passwort wird erst gar nicht abgefragt, man landet sofort mit root-Rechten in Prompt. Hat wahrscheinlich was mit Trusty Tahr zu tun.

Nein, das hat mit dem Schalter -d von passwd zu tun.

Siehe dazu man passwd

-d, --delete
           Löscht das Passwort eines Benutzers (macht es leer). Dies ist ein schneller Weg, um das Passwort eines Kontos zu deaktivieren. Dem Konto ist
           dann kein Passwort zugeordnet.

Dann verstehe ich diese Wiki-Aussage nicht:

Hat man einmal dem root-Benutzer ein Passwort gegeben und möchte dies wieder rückgängig machen, so kann man mit dem Befehl ´sudo passwd -d root´ den Account wieder in den "deaktivierten" Zustand bringen.

fu-sin schrieb:

Dann verstehe ich diese Wiki-Aussage nicht:

Hat man einmal dem root-Benutzer ein Passwort gegeben und möchte dies wieder rückgängig machen, so kann man mit dem Befehl ´sudo passwd -d root´ den Account wieder in den "deaktivierten" Zustand bringen.

Die dürfte auch falsch sein. Denn aktiv bleibt das Passwort, solange es nicht mit -l gesperrt wird (der Account wird dadurch auch nicht deaktiviert).

tomtomtom schrieb:

Die dürfte auch falsch sein.

Na, das beruhigt mich. ☺ Danke.

Da es aber unter dem Titel Root-Anmeldung untersagen steht, wird es vermutlich auch weiterhin verwirren.

Und von dem ´-l´ Schalter wird in dem Artikel ausdrücklich abgeraten.

Moin, mir fehlte hier noch eine kleine Info:

Ein Beispieleintrag für /etc/sudoers sieht so aus:

 root           ALL = (ALL) ALL

Das heißt root darf alle Befehle mit sudo ausführen.

Ich würde es so abändern:

Ein Beispieleintrag für /etc/sudoers sieht so aus:

 root           ALL = (ALL) ALL

Das heißt root darf von ALLen Terminals, als jeder user (ALL) ALLe Befehle mit sudo ausführen.

Wenn es keine Einwände gibt, tausche ich diese Zeile die Tage mal aus.

hannes22 schrieb:

Ein Beispieleintrag für /etc/sudoers sieht so aus:

 root           ALL = (ALL) ALL

Das heißt root darf von ALLen Terminals, als jeder user (ALL) ALLe Befehle mit sudo ausführen.

Ich persoenlich finde nicht, dass dieser Satz irgendetwas verbessert. Sicherlich ist er genauer, verkompliziert aber das Verstaendnis. Wenn du Wert auf eine Erklaerung aller Parameter legst, dann versuche doch bitte, dass in mehr als einem Satz zu formulieren.

aasche schrieb:

Ich persoenlich finde nicht, dass dieser Satz irgendetwas verbessert.

Full ACK.

Wenn du Wert auf eine Erklaerung aller Parameter legst, dann versuche doch bitte, dass in mehr als einem Satz zu formulieren.

Für die Erklärunge aller Parameter sollte™ die manpage da sein, kein Wikiartikel.

Hallo,

Sicherlich ist er genauer, verkompliziert aber das Verstaendnis.

+1

Wenn die drei ALL erklärt werden sollen, den entweder in mehreren Sätzen und in einer 3-teiligne Bullet List.

Gruß, noisefloor

Gut dann nicht.

Ich komme jetzt ja damit klar und wenn ihr es so haben wollt kann es gern so bleiben. Ich hätte es nur geändert, weil ich es hier nicht verstanden hatte. Entschuldigung!

Ich hatte genau diesen englischen Satz woanders gelesen und mir wurde es genügend klar um es anzuwenden und ich dachte: "Guter Satz". Also nichts für ungut.

Tschau!

Hannes

Hi,

ich untersuche grad steamOS und habe mich dort gefragt, wie es sein kann dass man als user steam, der nicht mal ein sudoer ist ein System-Update anschmeißen kann (via Big-Picture-Modus).

Habe nun entdeckt wie das geht und gleich hier im Wiki nachgeschaut, ob diese Methodik hier erwähnt ist.

Funktionieren tut das ganze wie folgt:

In /etc/sudoers.d/ lassen sich Regeln anlegen für Scripte, die mit sudo-Rechten ausgeführt werden können.

Im Fall von SteamOS gibt es unter /usr/bin/steamos-update ein Script mit folgendem Inhalt:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

#! /bin/sh

echo $$ > /tmp/steamos-update.pid

apt-get update -y -q
unattended-upgrade

# workaround for early images which didn't have nvidia-vdpau-driver:i386 preinstalled
if [ ! -f /usr/lib/i386-linux-gnu/vdpau/libvdpau_nvidia.so.1 ] ; then
    apt-get -y install nvidia-vdpau-driver:i386
fi

# workaround for early images which didn't have i965-va-driver:i386 preinstalled
if [ ! -f /usr/lib/i386-linux-gnu/dri/i965_drv_video.so ] ; then
    apt-get -y install i965-va-driver:i386
fi

# signal steam to refresh its inbox if we need a reboot
if [ -f /var/run/reboot-required ] && [ "`pidof -s steam`" != '' ] ; then
        STEAMPID=`pidof -s steam`
        STEAMUSER=`ps -p $STEAMPID -o user=`
        su $STEAMUSER -c steam steam://refreshinbox
fi

rm /tmp/steamos-update.pid

Diesem Script wird nun in der Datei /etc/sudoers.d/steamos-update das Recht vergeben, dass Jeder User das Script mittels sudo ausführen kann. Folgender Eintrag findet sich in der Datei:

ALL ALL=NOPASSWD: /usr/bin/steamos-update

Sollte das noch in den Artikel aufgenommen werden? Was meint ihr?

Klar, ein bisschen mehr Recherche und ein guter Quellenlink gehörte auch noch dazu, aber so generell passt das doch hier hinein, oder?

Wollte das kurz diskutieren, bevor ich einfach was drauf los ändere.

Gruß

André

Edit: Hatte natürlich geschaut, ob es das in meinem Kubuntu 14.04 auch gibt, damit klar ist, dass das nicht nur in Debian Jessie (worauf SteamOS basiert) verwendet wird 😉

Hallo,

Sollte das noch in den Artikel aufgenommen werden? Was meint ihr?

Nein - zumindest nicht in der Form.

1. Ist es IMHO eben _nicht_ Sinn der Sache, dass jeder unprivilegierte ein Syste-Upgrade machen kann.

2. Passt das wenn überhaupt in dieser Form in einen Steam-Artikel 3. Das das mit Skripten unter /etc/sudoers.d/ geht sollte wenn generischer beschrieben werden und nicht (sehr) speziell für Steam.

Gruß, noisefloor

Hi,

natürlich würde ich nicht das spezifische für den Artikel aufführen, sondern ganz generell einen Absatz zu /etc/sudoers.d/ machen. Schon klar, dass es hier um ubuntu geht und nicht um steamOS ^^

Ist mir nur bei der Untersuchung dieses Systems aufgefallen und ich habe das Beispiel hier festgehalten um als Basis für weitere Recherchen zu dienen.

Also lass uns mal Steam hier herausnehmen und generell überlegen, ob ein Absatz zu /etc/sudoers.d/ im Artikel sinn macht.

Gruß

André

Hallo,

ok - DAS ist ok ☺

Wenn du zu Ende nachgedacht hast einfach kurz melden, dann schieben wir den Artikel in die Baustelle.

Gruß, noisefloor