effective Berechtigungen werden gebildet, indem die tatsächlichen (echten?) Berechtigungen mit der mask UND-verknüpft werden . Seit dem mask Ihrer Datei ist rw- , alle effective Berechtigungen haben den x Bit ausgeschaltet.
Kurze Antwort:Wenn Sie eine Maske mit aktiviertem Ausführungsbit wünschen, müssen Sie dies explizit mit setfacl festlegen nach touch . Sicherheit verbietet seine implizite Einstellung.
setfacl -n -m m::rwx foo
"-n", um die Neuberechnung der Maske zu unterdrücken (wird möglicherweise nicht benötigt).
"m::rwx" setzt den Maskenwert auf 'rwx'. Beachten Sie, dass "m::x" alle Lese- und Schreibvorgänge deaktivieren würde.
Ich kann nicht zeigen, warum die Maske "rw-" ist. Ich gehe davon aus, dass das Standardverzeichnis touch ist die erstellte Datei bleibt für das gesamte OP-Beispiel unverändert.
-
Der Verzeichniseintrag für „foo“ sollte den Besitzer „root“ anzeigen (wegen des sudo-Befehls und der Gruppe „guards“, weil das Verzeichnis das SUID-Bit gesetzt hat. Die Berechtigungen sind standardmäßig „-rw-...r--“ mit die Gruppenberechtigungen des Verzeichnisses '-...r-x...' (aufgrund des SUID-Bits als kleines s dargestellt).
-
Als nächstes kommen die ACLs, die der Verzeichnisstandard sein sollten. Angesichts der Tatsache, dass ACLs erben, würde ich nicht erwarten, dass ACLes erstellt werden und dass die ACLE-Maske der Verzeichnisstandard „rwx“ ist.
Aber wenn sie erstellt werden, würde ich erwarten, dass die neuen ACLes von der Standardeinstellung vorbereitet werden, wobei die Maske wieder bei 'rwx' bleibt. Wenn sie nicht aus den Standardeinstellungen erstellt werden, scheint dies die Idee einer Standard-ACL zunichte zu machen – die "Standard"-ACL würde nur benannte Benutzer- und benannte Gruppen-ACLs bereitstellen.
Dies wirft nun die Frage auf, was die Maske ACLe sein soll. Ich würde erwarten, dass es 'rwx' aus dem Standardmaskeneintrag ist. Aber es könnte mit einer leeren Maske erstellt werden, und dann gilt allerlei Juristensprache.
- Mit einer vorläufigen ACL von user::rw-, group::r-x, other::r--, group:wheel:rwx, group:guards:rwx und mask:::(nicht gesetzt) konsultieren wir die Dokumentation für
setfacl, vorausgesetzt, die gleichen Regeln gelten für die Dateierstellung.
Es gibt eine Klausel:
Wenn eine ACL benannte Benutzer- oder benannte Gruppeneinträge enthält und kein Maskeneintrag vorhanden ist, wird ein Maskeneintrag mit denselben Berechtigungen wie der Gruppeneintrag erstellt.
Dies würde die ACL-Maske auf "r-x" setzen, wenn der ACL-Gruppeneintrag aus dem Dateiverzeichniseintrag erstellt wurde, oder auf "r-x", wenn der ACL-Gruppeneintrag aus der Standard-ACL stammte. (Egal, in diesem Fall ist das Ergebnis dasselbe.)
Es gibt auch eine Klausel:
Wenn eine Standard-ACL benannte Benutzereinträge oder benannte Gruppeneinträge enthält und kein Maskeneintrag vorhanden ist, wird ein Maskeneintrag hinzugefügt, der dieselben Berechtigungen wie der Gruppeneintrag der Standard-Standard-ACL enthält. ... die Berechtigungen des mask-Eintrags weiter angepasst werden, um die Vereinigung aller Berechtigungen einzuschließen, die vom mask-Eintrag betroffen sind.
Wenn diese Regel zutrifft, beginnt die Maske als "r-x" (gleiche Logik) wie im vorherigen Abschnitt) und wird dann so angepasst, dass sie die "Vereinigung aller Berechtigungen ist, die vom Maskeneintrag betroffen sind".
"Vom Maskeneintrag betroffene Berechtigungen" ist im setfacl nicht definiert Befehlsdokumentation. Die POSIX-ACL-Dokumentation sagt:
Die Maske ist die Kombination aller Zugriffsrechte der besitzenden Gruppe und aller Benutzer- und Gruppeneinträge.
Geben Sie das Wort "Vereinigung" an, das additiv ist. Ich würde "Kombination" als logisches ODER lesen. Mit anderen Worten, wenn eine Gruppen- oder Benutzer-ACLe die Berechtigung "x" hat, enthält die Maske "x".
- Nach all dieser Logik sollte der Maskenwert im OP-Beispiel 'rwx' sein, egal welcher logische Pfad befolgt wurde.
Die obige Argumentation muss fehlerhaft sein, da das x für execute nicht in der Maske erscheint.
Daher muss es eine Regel darüber geben, wie die Maske berechnet wird, die aus allgemeinen Dokumentationsquellen "versteckt" wurde (oder wir haben einen Fehler gefunden).
Meine Schlussfolgerung ist, dass das 'x' immer bedingungslos entfernt wird und die Dokumentation lasch ist.
Diese Änderung wurde wahrscheinlich aus Gründen der „Sicherheit“ vorgenommen – keine Datei soll implizit ausführbar sein, sondern muss das Ausführbarkeits-Bit aktiviert haben, nachdem sie erstellt wurde.