Почему 666 являются разрешениями на создание файлов по умолчанию?

Как я выяснил, при использовании umask максимальные разрешения, которые вы можете дать файлам, равны 666. Что и делается umask 0000. Это из-за разрешений на создание файлов по умолчанию, которые кажутся 666 в каждой системе, которую я знаю.

Я знаю, для файлов нам нужны права на исполняемые файлы, чтобы показать их содержимое.
Но почему мы ограничиваем разрешения по умолчанию для создания файлов на 666?

permissions filesystems files

— Питер
источник

Что за система? Единственное, umaskс

— кем

Нет, вы не поняли. Umask использует права доступа к файлу по умолчанию 666 и вычитает собственное значение (для вашей системы - 0022). Таким образом, наибольшее количество разрешений, которое вы можете установить, umask 0000- которое все еще ограничивает разрешения для файлов 666. (Но, очевидно, папки используют 777)

— Peter

Попался. Теперь это хороший вопрос.

— manatwork

Вам не нужны права на выполнение для просмотра содержимого файла. Это относится и к каталогам, поэтому каталоги создаются по умолчанию с разрешениями на выполнение.

— Джозеф Р.

Я полагаю [но мне нужно больше смотреть, чтобы быть уверенным], что это сделано специально, чтобы избежать некоторых проблем с безопасностью: без доступа к «chmod» вы не можете сделать файл исполняемым. umask 0000 создает файлы с 0666 и каталоги с 0777 [что, кстати, является довольно ужасной настройкой по умолчанию, с точки зрения безопасности!]

— Оливье Дюлак

Ответы:

Насколько я могу судить, это жестко запрограммировано в стандартные утилиты. Я straced одновременно touchсоздать новый файл и mkdirсоздать новый каталог.

touchСледа производится следующим образом :

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

в то время как mkdirслед произвел это:

mkdir("newdir", 0777)                   = 0

Если не считать кодирование процесса создания файла / каталога в C, я не вижу способа изменить разрешения по умолчанию. Однако мне кажется, что не делать файлы исполняемыми по умолчанию имеет смысл: вы не хотите, чтобы какой-либо случайный текст был случайно неверно истолкован как команды оболочки.

Обновить

Чтобы дать вам пример того, как биты разрешений жестко закодированы в стандартные утилиты. Вот некоторые соответствующие строки из двух файлов в coreutilsпакете, который содержит исходный код для обоих touch(1)и mkdir(1), среди прочего:

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

Другими словами, если режим не указан, установите для него значение S_IRWXUGO(читай: 0777), измененное параметром umask_value.

touch.c еще понятнее

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

То есть дать каждому право на чтение и запись (читай: 0666), что umask, конечно , будет изменено процессом создания файла.

Вы можете быть в состоянии обойти это программно только: то есть при создании файлов из любой программы C, где вы делаете системные вызовы напрямую или из языка , что позволяет сделать низкоуровневый системный вызов (смотрите, например , в Perl sysopenUnder perldoc -f sysopen).

— Джозеф Р.
источник

Вы правы, я не хочу никаких несчастных случаев. Но не иметь возможности изменить это, ужасно! Стандартные значения должны быть 777. А нам нужно umask fileи umask dir. Установите два разных значения по умолчанию и отлично. Но сейчас у меня нет возможности создавать файлы с exec perms.

— Питер

@PeterI Ну, mkdir(1)предлагает вам -mпереключатель, чтобы указать режим каталога во время создания. Однако с файлами, поскольку при создании файла используется open(2)системный вызов, инструмент, который вы используете для создания файла, - это тот, который отвечает за передачу битов режима, openи вы не получите права голоса в этом вопросе. install(1)по умолчанию копирует ваш файл в новое место и устанавливает биты выполнения, но это все еще не происходит во время создания.

— Джозеф Р.

То, что вы говорите, touchнапример, отвечает за установку правильных значений. Вы знаете, где хранятся значения? Может быть, они установлены по всей системе - чтобы мы могли их изменить? Потому что я хочу вырваться на свободу ;)

— Питер

@PeterI Смотрите обновленный ответ.

— Джозеф Р.

@PeterI Я снова обновил ответ. Вы можете сделать системный вызов непосредственно из C или другого языка, такого как Perl.

— Джозеф Р.

Во-первых, нет глобального значения по умолчанию, разрешения зависят от приложения, которое создает файл. Например, эта маленькая программа на C создаст файл '/ tmp / foo' с разрешениями 0777, если umask равен 0000 (в любом случае разрешения будут 0777 & ~ umask):

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

При этом многие приложения создают файлы с разрешениями 0666. У этого есть две причины:

Безопасность: вы не хотите, чтобы любой произвольный файл был исполняемым.
Удобство: большинство файлов не обязательно должны быть исполняемыми. Легче установить исполняемый бит для нескольких выбранных файлов, чем сбрасывать его для огромного количества других файлов. Конечно, umask 0133 решит эту проблему, но тогда ничего не выиграет, и вы не сможете позволить программам создавать исполняемые файлы, даже если вы этого хотите.

— Adaephon
источник

Файлы создаются без установленного бита x (execute) из соображений безопасности. Случайное выполнение файлов [cw] может быть «плохой вещью» (tm). Программа chmod дает вам возможность (пере) устанавливать биты прав доступа по мере необходимости.

— ChuckCottrill