Re: "umask" ist unlogisch?!

On Fri, Apr 04, 2003 at 07:49:25PM +0200, Oliver Lehmann wrote:
> Hallo,
>
> umask an sich ist mir klar. Man spezifiziert Rechte (indem man den
> entsprechenden 2^n Wert addiert) welche eine Datei beim anlegen
> nich haben soll. Soweit so gut.
>
> Also gebe ich z.B. 2 an, wenn ich nicht will das die betroffene "Einheit
> (u; g; o)" per default Schreibrecht auf die erstellte Datei hat. 4 wenn
> ich
> nicht will, das die Datei lesbar ist wenn sie angelegt wird. Und nun
> kommen wir zum Knackpunkt. das 1. Bit, das execute-bit. Wiso zum Teufel
> hat meine Datei kein x Bit, egal was ich bei umask einstelle? Wenn ich 0
> spezifiziere, dann doch weil ich _keine_ modes verbiete die eine Datei bei
> der Anlegung haben soll. also eben auch das x Bit. genauer rwx und nicht
> nur rw wie es aber der Fall ist. aktuell verhaellt es sich ja bei Dateien
> so, das 000 == 111 ist, was ja nunmal absolut nicht logisch ist.
>
> 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.

> 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.
Touch erstellt Dateien nur mit 666 - da kannst du soviel x und suid bits
maskieren, wie du willst.

> bei 000 verbiete ich keine Rechte. Somit kann ich doch erwarten, das jeder

Richtig.

> _alle_ Rechte auf die Datei hat nachdem sie angelegt wurde? Vielleicht

Nein - nur die, die für eine normale Datei normal sind.
Mit x bits ist es ja keine normale Datei mehr.

> 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.

> 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.

> olivleh1(at)kartoffel olivleh1> umask 111 && mkdir asdfg && ls -l |grep asdfg
> && rmdir asdfg
> drw-rw-rw- 2 olivleh1 wheel 512 Apr 4 19:39 asdfg/
> olivleh1(at)kartoffel olivleh1> umask 000 && mkdir asdfg && ls -l | grep
> asdfg && rmdir asdfg
> drwxrwxrwx 2 olivleh1 wheel 512 Apr 4 19:39 asdfg/
>
> 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.
Du müßtest ja schon in der Situation sein immer Programme anzulegen und
niermals Datendateien.
Schwer vorstellbar.

> Entscheidung soll gefaelligst nicht das OS fuer mich faellen, sondern mir
> diese Entscheidung auferlegen. Und wenn man dann kommt mit "Ja, aber wenn

Du wirst erstaunt sein, wieviele Entscheidungen das OS dir abnimmt.
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.

> 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 und ansonsten ist das Verhalten mit Datein und Verzeichnissen doch
identisch.

> 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.

Siehe chmod(1) Manpage:
           4000 (the set-user-ID-on-execution bit) Executable files with
                   this bit set will run with effective uid set to the uid of
                   the file owner. Directories with the set-user-id bit set
                   will force all files and sub-directories created in them to
                   be owned by the directory owner and not by the uid of the
                   creating process, if the underlying file system supports
                   this feature: see chmod(2) and the suiddir option to
                   mount(8).
           2000 (the set-group-ID-on-execution bit) Executable files with
                   this bit set will run with effective gid set to the gid of
                   the file owner.
           1000 (the sticky bit) See chmod(2) and sticky(8).
           0400 Allow read by owner.
           0200 Allow write by owner.
           0100 For files, allow execution by owner. For directories,
                   allow the owner to search in the directory.
           0040 Allow read by group members.
           0020 Allow write by group members.
           0010 For files, allow execution by group members. For directo-
                   ries, allow group members to search in the directory.
           0004 Allow read by others.
           0002 Allow write by others.
           0001 For files, allow execution by others. For directories
                   allow others to search in the directory.

> 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?

> 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.

-- 
B.Walter                   BWCT                http://www.bwct.de
ticso(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message