[DE] [gelöst] /etc/sudoers.d - wie funktioniert das?

[spacepenguin]

Neuerdings gibts ja für sudoers das Ergänzungs-Verzeichnis sudoers.d. Damit das genutzt wird, soll in der /etc/sudoers die Zeile "#includedir /etc/sudoers.d" drinstehen. Hab ich als letzte Zeile ergänzt bzw. beim Update ergänzen lassen.

Dann habe ich in /etc/sudoers.d mit dem Befehl "visudo -f /etc/sudoers.d/dummy" eine Datei erstellt mit folgendem Inhalt:

Code: [Select]

dummy ALL=/usr/bin/dpkg *, /usr/bin/apt-get *

Gemeckert hat visudo nicht. Die Datei hat die Berechtigung 0440. Trotzdem bekomme ich, auch nach Re-Boot und Re-Login, immer nur die Meldung, daß User dummy nicht in sudoers eingetragen ist. Das ganze funktioniert, wenn ich die o.g. Zeile direkt in /etc/sudoers drin habe...

Wo liegt der Hund denn da begraben?

[devil]

#includedir /etc/sudoers.d <=== das # hast entfernt?

greetz
devil

[spacepenguin]

Nein. Das war zwar das erste, was ich gemacht hatte, aber dann bekomme ich eine visudo-Fehlermeldung, daß in der Zeile etwas nicht stimmt. Ich hatte das auch so verstanden beim Update, daß das eine Anweisung ist, bei der der # erhalten bleiben soll?

[devil]

ich bin mir nicht sicher, da ich das nicht nutze und nicht weiss ob es sich an die üblichen konventionen hält. war daher eher ein schuss ins blaue.

greetz
devil

[agaida]

Ich bin mal ganz uncharmant und verweise auf eine Möglichkeit aus der Unix-Historie: "If anything else fail it could be useful to read the fucking manual!" - RTFM hat auch bei mir geholfen, bevor ich diesen Thread entedckt habe. Da das nicht die einzige Anfrage bleiben wird, hier die README aus dem /etc/sudoers.d/

Code: [Select]


#
# As of Debian version 1.7.2p1-1, the default /etc/sudoers file created on
# installation of the package now includes the directive:
#
#       #includedir /etc/sudoers.d
#
# This will cause sudo to read and parse any files in the /etc/sudoers.d
# directory that do not end in '~' or contain a '.' character.
#
# Note that there must be at least one file in the sudoers.d directory (this
# one will do), and all files in this directory should be mode 0440.
#
# Note also, that because the sudoers file is not a 'conffile' in the Debian
# sense, and sudoers contents can vary widely, no attempt is made to add this
# directive to existing sudoers files on upgrade.  Feel free to add the above
# directive to the end of your /etc/sudoers file to enable this functionality
# for existing installations if you wish!


Ich hab mich dann mal hingesetzt und das Folgende gepröbelt:

Code: [Select]


su
touch /etc/sudoers.d/agaida
chmod 0440 /etc/sudoers.d/agaida
nano /etc/sudoers.d/agaida
# User privilege specification
agaida  ALL=(ALL:ALL) ALL


Man beachte (ALL:ALL) statt (ALL). Finde ich irgendwie toll, diese Erweiterung, ich habe es immer gehasst, in den sudoers rumzufrickeln und bei updates darauf aufzupassen. Das ist damit ja wohl Geschichte.

[ralul]

Auf deutsch - wir haben vielleicht einige non-en Mitglieder:
Die Datei /etc/sudoers wird beim upgrade immer mal verändert. Eigene sudo Konfigurationen, die nicht geändert werden durch upgrades, können aufgerufen werden in /etc/sudoers per

#includedir /etc/sudoers.d

Wobei dann eigene Konfigs reingeschrieben werden in
/etc/sudoers.d/DeineKonfigDatei


@Agaida, was macht eigentlich das zusätzliche ":ALL"  ?

[agaida]

Das hab ich mich auch gefragt und einfach mal nachgelesen. Sorry, aber ich weigere mich, das in aller Breite zu übersetzen. Zusammenfassend: User- und Gruppenrechte als Neuheit.

Code: [Select]


/changelog

sudo (1.7.4p4-5) unstable; urgency=low

   * patch from Jakub Wilk to add noopt and nostrip build option support,
     closes: #605580
   * make sudoers a conffile, closes: #605130
   * add descriptions to LSB init headers, closes: #604619
   * change default sudoers %sudo entry to allow gid changes, closes: #602699
   * add Vcs entries to the control file
   * use debhelper install files instead of explicit installs in rules
 -- Bdale Garbee <bdale>  Wed, 01 Dec 2010 20:32:31 -0700

/#602699

From: Alexander Kurtz <kurtz>
To: submit@bugs.debian.org
Subject: Please change the default %sudo entry to allow ALL:ALL
Date: Sun, 07 Nov 2010 11:57:34 +0100
[Message part 1 (text/plain, inline)]
Package: sudo
Version: 1.7.4p4-2
Severity: wishlist

Hi,

the default sudoers configuration created by the postinst currently
contains these two entries:

root ALL=(ALL) ALL
%sudo ALL=(ALL) ALL

This allows any user in the sudo group and root to run any program as
any user. However if I want to change the GID (only) I get this:

$ sudo -g audio mplayer
Sorry, user alexander is not allowed to execute '/usr/bin/mplayer' as alexander:audio on alexander.

I found the explanation for this here [1]. Given that it is trivial to
change the GID after becoming root I suggest to change the default
entries to this:

root ALL=(ALL:ALL) ALL
%sudo ALL=(ALL:ALL) ALL

This allows the user to change the UID and the GID to match what he or
she needs more precisely. In my case this allows me to *not* use root
privileges when all I really need is access to my audio devices.

Best regards

Alexander Kurtz

PS: If you decide to make that change, it would be uber-cool if this
    would make it into squeeze ;-)

[1] http://serverfault.com/questions/166254/change-primary-group-with-sudo-u-g


[spacepenguin]

@agaida: Lies dir bitte nochmal meinen Eingangs-Post durch. Da steht nichts davon, daß ich das # entfernt habe. Gelesen hab ich die README natürlich auch, ich laß nicht einfach so eine Konfigurations-Datei bei einem Update überschreiben. Aber ich dachte, ich hab das evtl. falsch verstanden und daher auch mal ohne # probiert, als das mit nicht funktionierte. Und nachgefragt.

Manual- und README-posten hilft mir nicht wirklich weiter. Lesen kann ich selber, allein das Verständnis scheint ja wohl das Problem zu sein. Abgesehen davon, daß ich, wenn ich bewußt in einem deutschsprachigen Forum nachfrage, auch eine deutschsprachige Antwort erwarte. Trotzdem danke für deine Bemühungen.

Noch einmal meine Eingangsfrage: Wieso funtkioniert die erwähnte User-Zeile, wenn sie in der /etc/sudoers drinsteht, aber nicht, wenn sie in der /etc/sudoers.d/ in einer Datei steht und in der /etc/sudoers die Zeile "#includedir /etc/sudoers.d"? Mit dem ALL kann das eigentlich nichts zu tun haben, denn dann dürfte das auch nicht funktionieren, wenn die Zeile so in der /etc/sudoers steht?

Auch nach lesen das Manuals habe ich nicht verstanden, ob und falls ja wie ich die user-spezifische Zeile nun ggf. für diese neue Vartiante anpassen muß. Und ich habe es so verstanden, daß das mit dem ALL:ALL optional und halt jetzt nur default ist.

Das Manual nennt als sudo-Kommando-Begrenzung bestimmter User weiterhin folgende Syntax: "user ALL = Befehl"
und daran hält sich meine Zeile. Es geht also darum, warum das funktioniert, wenn es in /etc/sudoers aber nicht wenn in /etc/sudoers.d/sudoers.dummy steht.

[agaida]

Da ich des Lesens mächtig bin, habe ich gelesen, das Du die Raute entfernt und wieder zurückgesetzt hast. Das ist für die Direktive ja auch erforderlich.

Die beiden Postings waren auch nicht nur für Dich gedacht, das erste Posting klärt eigentlich nur, das diese eine Zeile, so wie sie das steht, das Lesen des /etc/sudoers.d/ aktiviert.

Das zweite Zitat war eigentlich auch nur die Antwort auf raluls Frage nach dem 2. ALL. Das haben ich dann mal nachgelesen, mich das auch interessierte. Ich habe es schon beim Posting geschrieben, dass ich mich weigere so etwas in epischer Breite zu übersetzen. Das liegt unter anderem daran, dass mein Englisch sehr gut dazu reicht, solche Sachen zu lesen, aber nicht dazu, das zweifelsfrei und auf jeden Fall richtig zu übersetzen. Da das Zitate sind, sehe ich da auch kein Problem drin.

Ich würde Dir trotzdem empfehlen, dir noch mal den Codeblock in meinem ersten Posting anzuschauen. Das ist kein Zitat, das ist bash. Und zwar genau die allgemeine Zeile, die ich normal in die sudoers geknallt hätte, in eine Datei in /etc/sudoers.d/ gelegt, Rechte angepasst nach Vorgabe und funktionierend.

An diesem allgemeinen Punkt würde ich ansetzen, den allgemeinen Fall funktionierend machen und wenn dass greift, auf das spezielle Problem herunterbrechen. Also erst sicherstellen, dass der Mechanismus überhaupt greift und dann das Eigentliche angehen.

[spacepenguin]

Es funktioniert nichts, was ich in /etc/sudoers.d/sudoers.dummy eintrage. Auch nicht die "globale" ALL:ALL Geschichte.

Die /etc/sudoers sieht wie folgt aus:

Code: [Select]

#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# 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) ALL

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

#includedir /etc/sudoers.d


Die /etc/sudoers.d/sudoers.dummy so:

Code: [Select]

# /etc/sudoers.d/sudoers.dummy
#
# This file MUST be edited with the 'visudo -f <file>' command as root.

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
dummy ALL=(ALL:ALL) ALL


[agaida]

Code: [Select]


# This will cause sudo to read and parse any files in the /etc/sudoers.d
# directory that do not end in '~' or contain a '.' character.


Ich will Dich nicht ärgern, aber das ist der Passus in der README. Frei übersetzt:

Code: [Select]


# Das bewirkt, dass sudo alle Dateien in /etc/sudoers.d liest und auswertet
# die nicht eine Tilde am Ende haben oder einen Punkt enthalten.


Dein Problem dürfte sich also so lösen lassen

Code: [Select]


mv /etc/sudoers.d/sudouers.dummy /etc/sudoers.d/dummy

Das liest sich erstens besser und kommt von der Sachlogik der Sache auch näher: Die Einstellungen für dummy liegen in der Datei dummy im Verzeichnis sudoers.d


EDIT: Wenn Du die beiden übersetzten Zeilen anschaust, wirst Du mein Problem mit dem übersetzen verstehen, der Google-Automat oder auch jedes andere Programm sind da besser drin.

[ralul]

Agaida hat Recht:
/etc/sudoers.d/DeineDateiOhnePunkt

Und Tschuldigung, dass ich den Thread gekapert habe, ich sehe ein, dass sowas nur zu Missverständnissen führt

[agaida]

Meine Ansicht dazu: Die Kaperung war an dieser Stelle keine wirkliche, die sudoers sehe ich als eine der elementaren Dateien in Linux an. Wenn da Veränderungen im Handling implementiert werden, sollten diese Änderungen auch entsprechend beleuchtet werden. Diese beiden Features sind neu und jetzt erschöpfend behandelt. Vielleicht wäre es eine Idee, so einen Punkt "Wichtige Änderungen" so in der Nähe von Update-Warnungen zu montieren.

An dieser Stelle stellt sich mir natürlich wieder einmal die Frage, was diese Art und Weise der Implementierung soll. Wenn ich mir /etc/apt/source.list.d/ anschaue, ist es dort sehr wohl möglich, Dateien mit Punkt zu parsen. Mir ist auch bewusst, dass einige Editoren Backups mit .irgendwas anlegen und die durch diese Einschränkung wirkungsvoll geblock werden. Spätestens, wenn ich Berechtigungen auf User oder Gruppen getrennt anlegen will, wird mir diese Einschränkung aber quer den Hals runtergehen.

Benennungen wie group.friends oder user.anne, user.alf sind dann nicht möglich. Um noch weiterzugehen: Solcherart Gängelung des Users kann ich nicht gutheissen. Meinetwegen kann alles, was in dem Verzeichnis drinsteht, auch geparst werden. Für meine Dateien bin ich als User selbst verantwortlich. Wenn jemand meint, fürsorglich sein zu müssen, sollen derjenige eine Warnung werfen, dass Sicherungen in diesem Verzeichnis keine gute Idee sind.

Dass es und wie es schiefgehen kann, haben wir ja jetzt an einem exemplarischen Beispiel gesehen. Das wird nicht das erste und nicht das letzte Mal sein, dass so was Unnötiges passiert. Linux soll nicht kuscheln, wenn ich kuscheln möchte, steichle ich meinen Hund.

[DonKult]

Naja, gerade APT gängelt seine Nutzer ja auch mit Dateinamen: Gib einer neuen Quelle einfach mal keine 'list' Endung und es wird nicht geparsed und erst seit neustem sich darüber beschwert. Das Problem mit Dateien ist, dass nicht nur der Anwender sie anlegt - oder ein Editor für ihn - sondern z.B. auch dpkg während es neue Versionen auspackt: Gerade von Konfigurationsdateien gibt es eine schirre Masse an .dpkg-{old,new,dist,tmp,…} und während sie sicher nützlich sind kann es nicht Aufgabe das Anwenders sein sich um diese zu kümmern wenn er nicht mag. Desweiteren gibt es einige Anwender (mich eingeschlossen) die Konfigurationsdateien temporär deaktivieren in dem sie sie umbenennen statt irgendwo hinzuverschieben wo sie nicht hingehören…

Das hat also eher selten was mit kuscheln zu tun, sondern mit Faulheit (aka Komfort) und ein wenig Sicherheit. Wobei ich mich nicht beschweren würde wenn sich Programme über falsche Konfigurationsdateien beschweren würden…

(APT hat übrigens auch etwas gegen Dateien mit Punkten drin… Bindestriche sollen helfen )

P.S.: sudo wird von aptosid nicht offiziell verwendet, da eine gute Konfiguration doch schon ein Problem für sich sein kann… Einige andere sehen das sicher anders, ich benutze es aber z.B. nicht (weil ichs nicht brauch, ich hab nämlich su und will weiterhin auf der 'Brave Kinder' Liste stehen).

[agaida]

Manchmal hätte ich gern was von dem Zeug, was beim Entwickeln geraucht wird, das muss gut sein. Die Liste ist gut, da will ich auch rauf. Da ich mir grade die Finger an Gnome und Ubuntu 10..10 breche: sudo passwd ist legitim und adäquat. Auch wenn die Buben diesen Hinweis in ihrem Forum nicht gerne sehen ...  :twisted:

Ein wenig mehr Einheitlichkeit wäre trotzdem schön. Deine Argumente leuchten mir natürlich ein. Ist halt alles eine Frage der Definition und Dokumentation. Aber der vorliegende Fall ist ja eigentlich eindeutig.