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

12

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?

Piotr
źródło
Jaki system? Jedyne, umaskco spotkałem, to zawsze 0022, tworząc domyślne uprawnienie 644.
manatwork
Nie, źle zrozumiałeś. Umask używa domyślnych uprawnień do plików 666 i odejmuje swoją wartość (która w systemie wynosi 0022). Więc najwięcej uprawnień, jakie możesz ustawić, to umask 0000- co nadal ogranicza uprawnienia do plików na poziomie 666. (Ale najwyraźniej foldery używają 777)
Peter
Mam cię. To dobre pytanie.
manatwork
2
Nie potrzebujesz uprawnień do wykonywania, aby zobaczyć zawartość pliku. Dzieje się tak w przypadku katalogów, dlatego katalogi są tworzone domyślnie z uprawnieniami do wykonywania.
Joseph R.
1
Wierzę [ale musiałbym bardziej się starać, aby mieć pewność], że jest to zgodne z projektem, aby uniknąć pewnych problemów bezpieczeństwa: bez dostępu do „chmod” nie można zrobić pliku wykonywalnego. umask 0000 tworzy pliki z 0666 i katalogi z 0777 [które, nawiasem mówiąc, jest dość okropnym ustawieniem domyślnym, jeśli chodzi o bezpieczeństwo!]
Olivier Dulac

Odpowiedzi:

10

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

Joseph R.
źródło
Masz rację, nie chcę żadnych wypadków. Ale nie można tego zmienić, to okropne! Standardowe wartości powinny wynosić 777. Potrzebujemy umask filei umask dir. Ustaw dwie różne wartości domyślne i dobrze. Ale teraz nie mam możliwości tworzenia plików za pomocą perm perms.
Peter
1
@PeterI Cóż, mkdir(1)oferuje -mprzełącznik umożliwiający określenie trybu katalogu w czasie tworzenia. Jednak w przypadku plików, ponieważ tworzenie plików korzysta z open(2)syscall, narzędzie, którego używasz do tworzenia pliku, jest tym, które jest odpowiedzialne za przekazywanie bitów trybu openi nie masz nic do powiedzenia w tej sprawie. install(1)domyślnie kopiuje plik do nowej lokalizacji i ustawia bity wykonania, ale nadal nie dzieje się tak w czasie tworzenia.
Joseph R.
To, co mówisz, że touchna przykład jest odpowiedzialny za ustawienie właściwych wartości. Czy wiesz, gdzie przechowuje wartości? Może są one ustawione na cały system - abyśmy mogli je zmienić? Bo chcę się uwolnić ;)
Peter
@PeterI Zobacz zaktualizowaną odpowiedź.
Joseph R.
1
@PeterI Zaktualizowałem odpowiedź ponownie. Możesz być w stanie wykonać połączenie systemowe bezpośrednio z poziomu C lub innego języka, takiego jak Perl.
Joseph R.
6

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.
Adaefon
źródło
1
Pliki są tworzone bez zestawu bitów x (execute) ze względów bezpieczeństwa. Nieumyślne wykonanie plików [cw] może być „Bad Thing” (tm). Program chmod umożliwia (ponowne) ustawianie bitów uprawnień w razie potrzeby.
ChuckCottrill