staging.inyokaproject.org

Neuer Artikel über einen vergessenen Befehl

Hi!

Hm, keine Diskussion dazu? Gleich ins Wiki verschoben? Entspricht eigentlich nicht so ganz den Vorgaben.

Ich hatte es zunächst noch mal umbenannt in "Baustelle/umask", aber dann gesehen, dass es bereits unter den Neuen ARtikeln aufgelistet ist. Also wieder umbenannt (dabei hat mein Handy ein großes U an den Anfang gesetzt, also das ganze nochmal (über den Umweg "Baustelle/Umask" zu "umask" - Inyoka lässt eine direkte Umwandlung nicht zu, wenn nur ein Großbuchstabe in einen kleinen verändert werden soll.)

so long
hank

Hallo,

Die Operation XOR kann man auch als AND NOT schreiben.

Ist IMHO mathematisch falsch. XOR heißt "exklusiv oder", d.h. einer der beiden Vergleichsoperanten wahr und der andere unwahr sein muss. Welcher was ist ist egal. AND NOT evaluiert immer zu falsch, wenn der erste Operant nicht wahr ist - das ist nicht das gleiche. Außerdem kann man IMHO nicht voraussetzen, dass jeder Leser so nerdig ist, dass er alle Logikoperationen kennt. Von daher wäre ein Link z.B. auf den XOR Wikipediaartikel sinnvoll.

Lt. Wiki/Syntax (Abschnitt „Textformatierung“) werden Befehl Monospace formitiert. Der Artikel bricht mit der Regel. Immerhin wird es explizit erwähnt, dass die Regeln für diesen Artikel anders sind.

Im Artikel Rechte wird umask zumindest gestreift bzw. kurz erklärt. Hier könnte ein geneigter Wikiautor noch auf Redundanzen und sinnvolle Verlinkung prüfen.

Gruß, noisefloor

Hallo,

was ist außerdem mit dem PAM-Link? Ich habe nichts von der Veröffentlichung eines solchen Artikels gehört.

Heinrich_Schwietering schrieb:

[…] keine Diskussion dazu? Gleich ins Wiki verschoben? Entspricht eigentlich nicht so ganz den Vorgaben.

Ich hatte das Problem im internen Wiki angesprochen. Unbeabsichtigt, vermutlich durch meine bisher von mir nicht verstandene Fehlbedienung, wurde der Artikel direkt im Wiki erstellt. Geplant war es anders.

noisefloor schrieb:

[…] Von daher wäre ein Link z.B. auf den XOR Wikipediaartikel sinnvoll.

Den Fehler bzgl. XOR habe ich korrigiert und auch auf einen erklärenden Wikipediaartikel verwiesen.

Lt. Wiki/Syntax (Abschnitt „Textformatierung“) werden Befehl Monospace formitiert.

Ja. Aber daraus folgt nicht, dass alles in Monospace formatierte auch ein Befehl sein muss. Wiki/Referenz verlangt u.a. auch für Optionen und Parameter diese Schreibweise. Deshalb trifft

Der Artikel bricht mit der Regel.

… nicht zu. Im Artikel steht UMASK immer für etwas, was Teil eines Befehls oder einer Zeile in einer Konfigurationsdatei ist ober sein könnte und entspricht damit den Vorgaben aus Wiki/Referenz.

Immerhin wird es explizit erwähnt, dass die Regeln für diesen Artikel anders sind.

Das steht auch da, weil ich nicht voraussetze, dass jeder Leser die Formatierungsvorgaben beherrscht.

Im Artikel Rechte wird umask zumindest gestreift bzw. kurz erklärt. Hier könnte ein geneigter Wikiautor noch auf Redundanzen und sinnvolle Verlinkung prüfen.

Ja, natürlich wird Rechte demnächst auch auf umask verweisen, und Redundanzen werden reduziert. Eins nach dem anderen und zwischendurch habe ich auch noch ein Leben außerhalb von UU.

karzer schrieb:

[…] was ist außerdem mit dem PAM-Link? Ich habe nichts von der Veröffentlichung eines solchen Artikels gehört.

Auch dazu siehe die Diskussion im internen Wiki. Ich habe das Monster halt falsch gefüttert und meinen Fehler erst beim dritten Mal bemerkt.

Hallo,

dass bei umask XOR verwendet wird, ist IMHO falsch. Es wird IMHO folgende Logik angewendet: "Programmatically, the mask is applied by the OS by first negating (complementing) the mask, and then performing a logical AND with the requested file mode." (https://en.wikipedia.org/wiki/Umask)

bugsbunny schrieb:

[…] dass bei umask XOR verwendet wird, ist IMHO falsch.

Indem Du in Deinem Satz das Wort "umask" generalisierst (Beachte: Der UbuntuUsers-de-Artikel unterscheidet drei mögliche Bedeutungen!) wird Dein Satz zwar manchmal richtig, aber im Generellen falsch sein. Richtig ist:

1. Nicht in allen für den Begriff umask denkbar sinnvollen Kontexten ist XOR richtig.

2. Bei der im Artikel besprochenen Situation, nämlich dem Anlegen einer Datei, trifft das hier mit Hilfe von XOR beschriebene Verhalten aber zu.

Es wird IMHO folgende Logik angewendet: "Programmatically, the mask is applied by the OS by first negating (complementing) the mask, and then performing a logical AND with the requested file mode." (https://en.wikipedia.org/wiki/Umask)

Dieser Wikipedia-Artikel bezieht sich auf eine andere (erkennbar an den von mir markierten Stellen) Situation als im hiesigen Wiki. Für eine andere Situation mag eine andere Art der Beschreibung besser geeignet sein, daraus folgt aber noch nicht, dass der hiesige Artikel falsch wäre.

Ich prüfe das aber noch mal in aller Ruhe.

kB schrieb:

[…] Ich prüfe das aber noch mal in aller Ruhe.

Ich habe zum Test mit dem Befehl

cd /tmp/ ; rm -rf /tmp/UMASK ; mkdir $_ ; cd $_ ; for i in {0..7}; do umask $i; touch $i; mkdir Dir_$i ; done; ls -l | zensiere 

neue Dateien und Ordner angelegt, wobei der Wert von UMASK jeweils in den Dateinamen übernommen wurde:

-rw-rw-rw- 1 █████ █████    0 Apr 18 14:22 0
-rw-rw-rw- 1 █████ █████    0 Apr 18 14:22 1
-rw-rw-r-- 1 █████ █████    0 Apr 18 14:22 2
-rw-rw-r-- 1 █████ █████    0 Apr 18 14:22 3
-rw-rw--w- 1 █████ █████    0 Apr 18 14:22 4
-rw-rw--w- 1 █████ █████    0 Apr 18 14:22 5
-rw-rw---- 1 █████ █████    0 Apr 18 14:22 6
-rw-rw---- 1 █████ █████    0 Apr 18 14:22 7
drwxrwxrwx 2 █████ █████ 4096 Apr 18 14:22 Dir_0
drwxrwxrw- 2 █████ █████ 4096 Apr 18 14:22 Dir_1
drwxrwxr-x 2 █████ █████ 4096 Apr 18 14:22 Dir_2
drwxrwxr-- 2 █████ █████ 4096 Apr 18 14:22 Dir_3
drwxrwx-wx 2 █████ █████ 4096 Apr 18 14:22 Dir_4
drwxrwx-w- 2 █████ █████ 4096 Apr 18 14:22 Dir_5
drwxrwx--x 2 █████ █████ 4096 Apr 18 14:22 Dir_6
drwxrwx--- 2 █████ █████ 4096 Apr 18 14:22 Dir_7

In allen Fällen lassen sich die erhaltenen Dateirechte so mittels XOR ermitteln, wie es im Artikel beschrieben wird.

Hier wurde nur mit der Gruppe „alle anderen“ experimentiert, es gibt aber keinen Grund zur Annahme, dass es sich mit den Berechtigungen für Besitzer und Gruppe der Datei anders verhalten würde.

Danke für Deine Rückmeldung und das gezeigte Beispiel.

Ausschnitt aus dem Artikel: "erlaubte Zugriffsarten für reguläre Dateien = 0666 XOR 0002 = 0664 erlaubte Zugriffsarten für Ordner = 0777 XOR 0002 = 0775 Die beiden Oktalzahlen werden bitweise miteinander verknüpft. Der nicht veränderbare Standardwert für „alle Zugriffsarten“ ist 0666 für reguläre Dateien und 0777 für Ordner."

Ich habe unten einmal für alle Fälle (jeweils nur ein Berechtigungsbit, wie in Deinem Beispiel) einmal alle bitweisen Verknüpfungen ausgeschrieben. Man kann erkennen, dass es bei Ordner keinen Unterschied macht, ob wir XOR oder die Mask erst negieren und dann das logische UND anwenden. Bei den Dateien, wo wir von dem Standardwert 6 ausgehen, macht es allerdings einen Unterschied. Bei den "ungeraden" Masks kommt es zu Abweichungen. Es würden sogar teilweise Rechte hinzukommen. Mit Negieren der Mask und anschließender Anwendung des logischen UNDs, werden die Bits ermittelt, die auch in Deinen beispielhaft angelegten Dateien zu sehen sind.

Wenn wir also von 6 als nicht veränderbarer Standardwert für Dateien ausgehen und bitweise die Oktalzahlen verknüpfen, dann kommen wir nicht mit XOR, sondern nur mit Negierung der Mask und anschließendem logischem UND auf die entsprechenden Berechtigungsbits der angelegten Dateien. Vielleicht habe ich aber auch etwas falsch verstanden?

Dateien:

XOR:

6 XOR 0 = 110 XOR 000 = 110 = 6
6 XOR 1 = 110 XOR 001 = 111 = 7
6 XOR 2 = 110 XOR 010 = 100 = 4
6 XOR 3 = 110 XOR 011 = 101 = 5
6 XOR 4 = 110 XOR 100 = 010 = 2
6 XOR 5 = 110 XOR 101 = 011 = 3
6 XOR 6 = 110 XOR 110 = 000 = 0
6 XOR 7 = 110 XOR 111 = 001 = 1

Negieren und logisches UND:

6 AND ~0 = 110 AND ~000 = 110 = 6
6 AND ~1 = 110 AND ~001 = 110 = 6
6 AND ~2 = 110 AND ~010 = 100 = 4
6 AND ~3 = 110 AND ~011 = 100 = 4
6 AND ~4 = 110 AND ~100 = 010 = 2
6 AND ~5 = 110 AND ~101 = 010 = 2
6 AND ~6 = 110 AND ~110 = 000 = 0
6 AND ~7 = 110 AND ~111 = 000 = 0

Ordner:

XOR:

7 XOR 0 = 111 XOR 000 = 111 = 7
7 XOR 1 = 111 XOR 001 = 110 = 6
7 XOR 2 = 111 XOR 010 = 101 = 5
7 XOR 3 = 111 XOR 011 = 100 = 4
7 XOR 4 = 111 XOR 100 = 011 = 3
7 XOR 5 = 111 XOR 101 = 010 = 2
7 XOR 6 = 111 XOR 110 = 001 = 1
7 XOR 7 = 111 XOR 111 = 000 = 0

Negieren und logisches UND:

7 AND ~0 = 111 AND ~000 = 111 = 7
7 AND ~1 = 111 AND ~001 = 110 = 6
7 AND ~2 = 111 AND ~010 = 101 = 5
7 AND ~3 = 111 AND ~011 = 100 = 4
7 AND ~4 = 111 AND ~100 = 011 = 3
7 AND ~5 = 111 AND ~101 = 010 = 2
7 AND ~6 = 111 AND ~110 = 001 = 1
7 AND ~7 = 111 AND ~111 = 000 = 0

PS: Mir ist ein Copy-Paste-Fehler beim Ausschreiben der ersten Operatoren unterlaufen, den ich nun korrigiert habe.

bugsbunny schrieb:

[…] Vielleicht habe ich aber auch etwas falsch verstanden?

Nein, Du hast im Ergebnis doch recht. Ich berücksichtige das im Artikel.

kB schrieb:

bugsbunny schrieb: Nein, Du hast im Ergebnis doch recht. Ich berücksichtige das im Artikel.

Danke für die Korrektur des Artikels.

Ich fand den alten Satz "Der nicht veränderbare Standardwert für „alle Zugriffsarten“ ist 0666 für reguläre Dateien und 0777 für Ordner." aus dem Artikel im übrigen auch sehr hilfreich für das Verständnis. Nochmal als expliziter Hinweis, dass reguläre Dateien standardmäßig nicht ausführbar sind. Vielleicht macht es Sinn diesen zusätzlich wieder mit zu integrieren. Ansonsten eine gute Erklärung.