Dlaczego 666 są domyślnymi uprawnieniami do tworzenia plików?

Jak się dowiedziałem, podczas korzystania z umask najwyższe uprawnienia, jakie możesz nadać plikom, to 666. Robi to umask 0000. Wynika to z domyślnych uprawnień do tworzenia plików, które wydają się wynosić 666 w każdym znanym mi systemie.

Wiem, że w przypadku plików potrzebujemy praw wykonywalnych, aby pokazać ich zawartość.
Ale dlaczego ograniczamy domyślne uprawnienia do tworzenia plików w 666?

O ile wiem, jest to na stałe zapisane w standardowych narzędziach. Mogę utworzyć stracezarówno touchnowy plik, jak i mkdirnowy katalog.

touchŚlad produkowane w ten sposób:

open("newfile", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 3

podczas gdy mkdirślad dał to:

mkdir("newdir", 0777)                   = 0

Poza kodowaniem procesu tworzenia pliku / katalogu w C, nie widzę sposobu modyfikowania domyślnych uprawnień. Wydaje mi się jednak, że brak domyślnego wykonywania plików ma sens: nie chcesz, aby przypadkowy tekst był przypadkowo błędnie interpretowany jako polecenie powłoki.

Aktualizacja

Aby dać przykład, w jaki sposób bity uprawnień są na stałe zakodowane w standardowych narzędziach. Oto kilka odpowiednich wierszy z dwóch plików w coreutilspakiecie, który zawiera kod źródłowy zarówno dla, jak touch(1)i mkdir(1)między innymi:

mkdir.c:

if (specified_mode)
   {   
     struct mode_change *change = mode_compile (specified_mode);
     if (!change)
       error (EXIT_FAILURE, 0, _("invalid mode %s"),
              quote (specified_mode));
     options.mode = mode_adjust (S_IRWXUGO, true, umask_value, change,
                                  &options.mode_bits);
     free (change);
   }   
  else
    options.mode = S_IRWXUGO & ~umask_value;
}   

Innymi słowy, jeśli tryb nie jest określony, ustaw go na S_IRWXUGO(odczyt: 0777) zmodyfikowany przez umask_value.

touch.c jest jeszcze jaśniejszy:

int default_permissions =
  S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH;

To znaczy, daj wszystkim uprawnienia do odczytu i zapisu (odczyt: 0666), które umaskoczywiście zostaną zmodyfikowane przez proces tworzenia pliku.

Możesz być w stanie obejść ten problem tylko programowo: tj. Podczas tworzenia plików z poziomu programu C, w którym wywołujesz system bezpośrednio lub z poziomu języka, który pozwala na wywołanie syscall niskiego poziomu (patrz na przykład Perl sysopenpod perldoc -f sysopen).

Po pierwsze, nie ma globalnej wartości domyślnej, uprawnienia zależą od aplikacji, która tworzy plik. Na przykład ten mały program w języku C utworzy plik „/ tmp / foo” z uprawnieniami 0777, jeśli umask ma wartość 0000 (w każdym przypadku uprawnienia to 0777 i ~ umask):

int main() 
{
   creat("/tmp/foo", 0777);
   return 0;
}

To powiedziawszy, wiele aplikacji tworzy pliki z uprawnieniami 0666. Ma to dwa powody:

1. Bezpieczeństwo: nie chcesz, aby dowolny plik był wykonywalny.
2. Wygoda: większość plików nie musi być wykonywalna. Łatwiej jest ustawić bit wykonywalny na kilku wybranych plikach niż rozbroić go na ogromnej ilości innych plików. Oczywiście umask 0133 rozwiązałby ten problem, ale wtedy nic nie jest wygrane i nie można pozwolić programom tworzyć plików wykonywalnych, nawet jeśli chcesz.