Warum sind 666 die Standardberechtigungen zum Erstellen von Dateien?


12

Wie ich herausgefunden habe, sind bei Verwendung von umask die höchsten Berechtigungen, die Sie Dateien erteilen können, 666. Dies geschieht durch umask 0000. Dies liegt an den Standardberechtigungen für die Dateierstellung, die auf jedem mir bekannten System 666 zu sein scheinen.

Ich weiß, dass wir für Dateien ausführbare Rechte benötigen, um deren Inhalt anzuzeigen.
Aber warum beschränken wir die Standardberechtigungen für die Dateierstellung auf 666?


Was für ein System? Das Einzige, das umaskich traf, war immer 0022, wodurch die Standardberechtigung
644 erstellt wurde.

Nein, du hast es falsch verstanden. Umask verwendet die Standarddateiberechtigungen von 666 und subtrahiert seinen eigenen Wert (0022 für Ihr System). Die meisten Berechtigungen, die Sie festlegen können, sind umask 0000- was immer noch auf Dateiberechtigungen von 666 beschränkt ist. (Aber anscheinend verwenden Ordner 777)
Peter,

Hab dich. Das ist eine gute Frage.
Manatwork

2
Sie benötigen keine ausführbaren Berechtigungen, um den Dateiinhalt anzuzeigen. Dies gilt für Verzeichnisse. Aus diesem Grund werden Verzeichnisse standardmäßig mit Ausführungsberechtigungen erstellt.
Joseph R.

1
Ich glaube, dass dies beabsichtigt ist, um einige Sicherheitsprobleme zu vermeiden. Ohne Zugriff auf "chmod" können Sie eine Datei nicht ausführbar machen. umask 0000 erstellt Dateien mit 0666 und Verzeichnisse mit 0777 [was übrigens eine ziemlich schreckliche Standardeinstellung ist, was die Sicherheit betrifft!]
Olivier Dulac

Antworten:


10

Soweit ich das beurteilen kann, ist dies in Standarddienstprogrammen fest programmiert. Ich würde stracesowohl eine touchneue Datei als auch mkdirein neues Verzeichnis erstellen.

Die touchSpur erzeugte dies:

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

während die mkdirSpur dies erzeugte:

mkdir("newdir", 0777)                   = 0

Abgesehen von der Codierung des Datei- / Verzeichniserstellungsprozesses in C sehe ich keine Möglichkeit, die Standardberechtigungen zu ändern. Ich halte es jedoch für sinnvoll, Dateien nicht standardmäßig ausführbar zu machen: Sie möchten nicht, dass zufälliger Text versehentlich als Shell-Befehl missverstanden wird.

Aktualisieren

Um Ihnen ein Beispiel zu geben, wie die Berechtigungsbits in den Standarddienstprogrammen fest codiert sind. Hier sind einige relevante Zeilen aus zwei Dateien im coreutilsPaket, die den Quellcode für beide touch(1)und mkdir(1)unter anderem enthalten:

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;
}   

Mit anderen Worten, wenn der Modus nicht angegeben ist, setzen Sie ihn auf S_IRWXUGO(read: 0777) modified by the umask_value.

touch.c ist noch klarer:

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

Geben Sie also allen Benutzern Lese- und Schreibberechtigungen (read: 0666), die umasknatürlich durch den Vorgang bei der Dateierstellung geändert werden .

Möglicherweise können Sie dies nur programmgesteuert umgehen: Beim Erstellen von Dateien in einem C-Programm rufen Sie das System direkt oder in einer Sprache auf, mit der Sie einen einfachen Systemaufruf durchführen können (siehe z. B. Perl sysopenunter perldoc -f sysopen).


Sie haben recht, ich will keine Unfälle. Aber keine Möglichkeit zu haben, es zu ändern, ist schrecklich! Standardwerte sollten 777 sein. Und wir brauchen umask fileund umask dir. Legen Sie zwei verschiedene Standardwerte und fein fest. Aber jetzt habe ich keine Möglichkeit, Dateien mit exec-Berechtigungen zu erstellen.
Peter

1
@ PeterI Nun, mkdir(1)bietet Ihnen einen -mSchalter, um den Modus des Verzeichnisses bei der Erstellung anzugeben. Da die open(2)Dateierstellung bei Dateien jedoch syscall verwendet, ist das Tool, mit dem Sie die Datei erstellen, für die Übergabe der Modusbits verantwortlich, openund Sie haben in dieser Angelegenheit kein Mitspracherecht. install(1)Standardmäßig kopiert Ihre Datei an einen neuen Speicherort und setzt die Ausführungsbits. Dies geschieht jedoch zum Zeitpunkt der Erstellung noch nicht.
Joseph R.

Was Sie sagen, das ist touchzum Beispiel dafür verantwortlich, die richtigen Werte einzustellen. Wissen Sie, wo die Werte gespeichert werden? Vielleicht sind sie systemweit festgelegt - also könnten wir sie ändern? Weil ich mich befreien will ;)
Peter

@ PeterI Siehe die aktualisierte Antwort.
Joseph R.

1
@PeterI Ich habe die Antwort erneut aktualisiert. Möglicherweise können Sie den Syscall direkt in C oder einer anderen Sprache wie Perl ausführen.
Joseph R.

6

Zunächst gibt es keinen globalen Standard. Die Berechtigungen hängen von der Anwendung ab, mit der die Datei erstellt wird. Zum Beispiel erstellt dieses kleine C-Programm eine Datei '/ tmp / foo' mit den Berechtigungen 0777, wenn umask 0000 ist (in jedem Fall sind die Berechtigungen 0777 & ~ umask):

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

Davon abgesehen erstellen viele Anwendungen Dateien mit den Berechtigungen 0666. Das hat zwei Gründe:

  1. Sicherheit: Sie möchten nicht, dass eine beliebige Datei ausführbar ist.
  2. Bequemlichkeit: Die meisten Dateien müssen nicht ausführbar sein. Es ist einfacher, das ausführbare Bit für einige ausgewählte Dateien festzulegen, als es für die große Menge anderer Dateien zu deaktivieren. Natürlich würde umask 0133 das lösen, aber dann ist nichts gewonnen und Sie könnten nicht zulassen, dass Programme ausführbare Dateien erstellen, selbst wenn Sie wollten.

1
Aus Sicherheitsgründen werden Dateien ohne gesetztes x-Bit (Ausführen) erstellt. Die versehentliche Ausführung von Dateien [cw] könnte ein "Bad Thing" (tm) sein. Mit dem Programm chmod können Sie die Berechtigungsbits nach Bedarf (neu) setzen.
ChuckCottrill
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.