Re: "umask" ist unlogisch?!

From: Jens Rehsack <rehsack(at)liwing.de>
Date: Fri, 04 Apr 2003 21:46:43 +0200

On 4/4/2003 9:02 PM, Oliver Lehmann wrote:
> Bernd Walter wrote:
>
>> On Fri, Apr 04, 2003 at 07:49:25PM +0200, Oliver Lehmann wrote:
>>
>> > olivleh1(at)kartoffel olivleh1> umask 000 && touch qwerty && ls -l qwerty
>> > && rm -f qwerty
>> > -rw-rw-rw- 1 olivleh1 wheel 0 Apr 4 19:37 qwerty
>>
>> Du hast nichts maskiert (000) und 666 erhalten.
>> Ist doch OK.
>
> Eben, ich habe nichts maskiert, und somit erwarte ich die vollen rechte
> und nicht 666 (was einem umask von 111 entsprechen wuerde das bei umask
> 000 bei Dateien 666 und nicht 777 rauskommt, liegt halt einfach daran bei
> der umask zw. Dateien und Verz. unterschieden wird )
>

pseudo_code:

1: int
2: open( const char *path, int flags )
3: {
4: int mask = syscall( GET_UMASK );
5: flags &= (~mask & 04777);
6: return syscall( path, flags );
7: }

Natürlich ist das in Wahrheit etwas komplizierter, aber so in etwas
musst Du Dir das vorstellen.

Wenn Du open(2) jetzt mit path = "/tmp/test" und flags = 0777 aufrufst,
umask 000 ist, wird eine Datei mit den Rechten 0777 angelegt. Rufst Du
open(2) mit flags = 0666 auf (wie touch(1) dies tut), wird die Datei mit
den Rechten 0666 angelegt. Christian hat das IMHO sehr gut beschrieben.

>> > olivleh1(at)kartoffel olivleh1> umask 111 && touch qwerty && ls -l qwerty
>> > && rm -f qwerty
>> > -rw-rw-rw- 1 olivleh1 wheel 0 Apr 4 19:37 qwerty
>> > olivleh1(at)kartoffel olivleh1>
>>
>> Du hast 111 maskiert und 666 erhalten - ist doch logisch, da kein x bit
>> gestetzt war.
>
> Da ist es logisch - natuerlich. Streite ich auch nicht ab. nur das davor
> (000 -> 666) ist unlogisch ;)
>
>> Touch erstellt Dateien nur mit 666 - da kannst du soviel x und suid bits
>> maskieren, wie du willst.
>
> Touch, oder generell, sollte Dateien so erstellen wie ich ihm das mit
> umask einbleue und nicht wie es meint Dateien erstellen zu moechten. Da
> kann ich mir umask auch gleich sparren.

Nein, denn touch ist kein Werkzeug, dass ausführbare Dateien erstellt.
touch(1) ist ein Werkzeug, dass das Datum einer Datei auf den
gewünschten Timestamp aktualisiert und ggf. eine nicht existierende
Datei anlegt.

>> Nein - nur die, die für eine normale Datei normal sind.
>> Mit x bits ist es ja keine normale Datei mehr.
>
> Ich will entscheiden was normal ist!

Dann schreib' touch(1) um. Die Maske funktioniert wie eine Maske, sie
verbietet die Sachen, die Du nicht willst. Du suchst wahrscheinlich eine
Funktionalität, die in obigem Beispiel in Zeile 5

5: flags |= want_mask; flags &= ~mask; flags &= 04777;

macht. Tja, aber umask ist dafür nicht zuständig.

>> > will ich ja, das alle Dateien die ich anlege per default ausfuehrbar
>> > sind?
>>
>> Warum - die sind es doch erst, wenn auch der Inhalt entsprechend ist.
>
> Technisch sie sind ausfuehrbar wenn ich ein execute bit setze. Dann ist
> immer noch unwichtig was in den Dateien steht. Auch wenn es JPEG Daten
> sind ist diese theoretisch erstmal ausfuehrbar.

Nein, technisch sind die ausführbar, sobald ausführbarer Inhalt drin
ist. Beispiel: ls -l /usr/sbin/ppp

>> > Oder weil ich Purist in Sachen Anarchie bin, will ich vielleicht 777
>> > als default Dateirechte? wiso zum Teufel verhaellt sich das entgegen
>> > der"Logik"? Wiso wird dabei zw Verzeichnisse und Dateien
>> > unterschieden?
>>
>> Weil eine Datei eine Datei und ein Verzeichniss ein Verzeichniss ist.
>> Die default werte sind bei einem Verzeichniss anders, da das x bit bei
>> Verzeichnissen eine andere Bedeutung hat, wie das sticky bit übrigens
>> auch.
>
> Ok, aber wenn ich x nicht verbiete, erwarte ich einfach, logisch
> schlussfolgernd, das ich das x bit gesetzt bekomme *wiederhol*

Aber von wem erwartest Du das?

>> > Man moege mir das logisch erklaeren und nicht mit dem Punkt kommen
>> > "Ja, aber per default x Bit auf alle neuen Dateien ist doch
>> > unlogisch!" Diese
>>
>> Es ist nicht unlogisch, sondern unsinnig.
>
> Das kannst du so keinesfalls sagen! Du magst dir keine Situation

Offensichtlich kann er es doch :-)

> vorstellen koennen wo das sinnvoll ist. Aber das bedeutet noch lange nicht
> das es so eine Situation nicht geben kann. Ist es nicht leicht engstirnig
> zu behaupten das es etwas nicht gibt, nur weil man es sich nicht
> vorstellen kann? Gibt es auch kein unendlich? ;)

Abzählbar oder überabzählbar?

>> Du müßtest ja schon in der Situation sein immer Programme anzulegen und
>> niermals Datendateien.
>> Schwer vorstellbar.
>
> Schwer vorstellbar mag sein.. Aber vielleicht besteht genau diese
> Anforderung? Wiso bevormundet mich UNIX Dort in so einer lapidaren
> Angelegenheit?

UNIX? War es nicht eben noch touch(1), dass Dich bevormundet hat?

>> So kannst du z.B. als User keine ausführbaren Programme mit suid und
>> User root anlegen.
>> Du kannst auch nicht die hidden Fileflags setzen, die zwischen
>> Directory, Device, Datei und sonstigem unterscheiden.
>
> Das ist glaub ich nicht vergleichbar mit einem "per default x bit fuer
> alle Dateien"...

Das ist aber eine additive Funktionalität, umask ist eine subtraktive.

>> > du x verbietest wenn du das nicht auf Dateien willst sind deine
>> > Verzeichnisse 'putt'", haette man sich halt ein anderes Konzept bei
>> > der Implementierung von umask entwickeln muessen (z.b. getrennte
>> > umasks fuer
>>
>> Verstehe ich nicht - das x Flag bei Files macht doch nur in Ausnahmen
>> Sinn
>
> Was fuer dich Ausnahmen sind, kann fuer andere Bedingungen der Normalfall
> sein.

Eigendlich nicht. Ich erstelle recht selten ausführbare Dateien direkt.
Meistens übernimmt der Compiler das für mich. Und irgendwie sehe ich
keinen Sinn darin, meinen c-source ausführbar zu machen. Es ist wohl
doch eher so, dass Dein scheinbarer Normalfall eine Ausnahme ist.

>> und ansonsten ist das Verhalten mit Datein und Verzeichnissen doch
>> identisch.
>
> bis aufs x bit - ja
>
>
>> > files und verz.). Ich mein, es ist ja schon schwer, einem absolutem
>> > Newbie zu vermitteln, das man bei fehlen des x Bits ("aber das heisst
>> > doch ausfuehrbar") nicht in ein Verzeichniss wechseln kann, aber dann
>>
>> Nein - das heißt listbar.
>
> okok - was sich fuer einen Laien aber erstmal so darstellt, das er nicht
> in das Verzeichniss wechseln kann (weder ein ls um halt was zu listen,
> noch mit einem cd).

Ja, aber deshalb kann das Verzeichnis noch lange nicht ausgeführt werden.

>> > schluessig umask zu erklaeren ist quasi unmoeglich. Etwas wie "ist
>> > halt
>>
>> Verstehe ich nicht eine Maske maskiert - was nicht da ist kann auch
>> nicht maskiert werden - wo ist das unschlüssig?
>
> Ich maskiere mit umask das er das x bit nicht nicht setzen soll (ja,
> 2*nicht), und es ist trozdem nicht gesetzt bei Dateien? Aeusserst
> schluessig!

In der Tat. Schon mal 'ne Logik-Vorlesung besucht? IMHO bietet jede
Philosophische Fakultät eine pro Studienjahr, manche sogar pro Semester.

>> > so" praegt sich schwerer ein als wenn man eine moeglichst plausible
>> > Erklaerung liefert ohne "ja, aber da gilt das nicht, und da auch
>> > nicht, und dabei erst recht nicht".... Ausnahmen sind immer sehr
>> > unlogisch (siehe natuerliche Sprachen...)
>>
>> Ich sehe da keine Ausnahmen.
>
> Die umask unterschiedlich auf die reinen Rechte von Verz. und Dateien
> anzuwenden ist in meinen Augen sehr wohl eine "Ausnahme"

umask auf Dateien und Verzeichnisse unterschiedlich? Meine Manpage sagt
da aber was ganz anderes.

> Hat schonmal wer von Euch Leuten die 20 Jahre mit OS/390 gearbeitet haben
> und die "UNIX" fuer einen Schreibfehler halten Grundlagen der
> Shellverarbeitung naeherzubringen um dann dies auf Shellprogrammierung
> auszuweiten?

Ja. War zwar Perl, aber was hat das mit umask zu tun?

> Ich find es ja selber "unlogisch". Klar weiss ich um den Fakt das die
> Maske untersch. fuer Dateien und verz. angewand wird. nur dieser "Fakt"
> ist halt in sich unlogisch. Ist halt so ;)

Aus /usr/src/bin/mkdir/mkdir.c:
        if (mode == NULL) {
                omode = S_IRWXU | S_IRWXG | S_IRWXO;
        } else {
                if ((set = setmode(mode)) == NULL)
                        errx(1, "invalid file mode: %s", mode);
                omode = getmode(set, S_IRWXU | S_IRWXG | S_IRWXO);
                free(set);
        }

Aus mkdir(2):
int
mkdir(const char *path, mode_t mode);

Aus /usr/src/usr.bin/touch/touch.c:
fd = open(*argv,
O_WRONLY | O_CREAT, DEFFILEMODE);

Wo ist die Unlogik? Sollte man DEFFILEMODE auch auf Verzeichnisse
anwenden, obwohl Verzeichnisse per Definition keine Standarddateien
sind? Sollte jede(r) Anwender(in) eines Unix-Systems alle Dateien, die
er/sie sich selbst erstellt, ausführen können, wenn er/sie das
umask-Kommando noch nicht kennt? Oder sollte umask per default
ausführbare Dateien verbieten? Muss dann ein Anfänger in C erstmal
lernen, dass er wählen kann, zwischen allen Dateien ausführen (auch
source + header) oder gar keine?

Kannst Du mir die Logik hinter Deiner Forderung näher bringen?

So long,
Jens

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Fri 04 Apr 2003 - 21:46:54 CEST