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

Можно просто использовать *; нет никакой потребности в *.*. Расширения файла не являются особенными на Unix. * нуль соответствий или больше символов — включая точку. Таким образом, это соответствует foo.png, потому что это - нуль или больше символов (семь, чтобы быть точным).

Отметьте это * по умолчанию не соответствует файлам, начинающимся с точки (ни один не делает *.*). Это часто, что Вы хотите. В противном случае в ударе, если Вы shopt -s dotglob это будет (но все еще исключать . и ..). Другие оболочки имеют различные пути (или ни один вообще) включения dotfiles.

С другой стороны, zip также имеет a -r (рекурсивная) опция сделать все деревья каталогов сразу (и не иметь для волнения о dotfile проблеме):

zip -r myfiles.zip mydir

где mydir каталог, содержащий Ваши файлы. Обратите внимание, что произведенная zip будет содержать структуру каталогов, а также файлы. Как peterph указывает в его комментарии, это обычно рассматривается как хорошая вещь: извлечение zip будет аккуратно хранить все извлеченные файлы в одном подкаталоге.

Можно также сказать zip не снабжать пути -j/--junk-paths опция.

zip команда идет с документацией, говоря Вам обо всем (много) опции; ввести man zip видеть ту документацию. Это не уникально для zip; можно получить документацию для большинства команд этот путь.

12
21.11.2013, 14:37
2 ответа

Насколько я могу сказать, это трудно кодируется в стандартные утилиты. Я straced оба a touch создание нового файла и a 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, где Вы делаете системные вызовы непосредственно или из языка, который позволяет Вам делать низкий уровень syscall (см., например, Perl sysopen под perldoc -f sysopen).

10
27.01.2020, 19:55
  • 1
    , Вы правы, я не хочу несчастных случаев. Но не иметь никакого способа изменить его, ужасно! Стандартные значения должны быть 777. И нам нужно umask file и umask dir. Установите два различных значения по умолчанию и прекрасный. Но теперь у меня нет способа создать файлы с должностным лицом перманент. сжатие –  Peter 21.11.2013, 15:10
  • 2
    @PeterI ну, mkdir(1) действительно предлагает Вам a -m переключатель для определения режима каталога во время создания. С файлами, однако, так как создание файла использует open(2) syscall, инструмент, который Вы используете для создания файла, является тем, к которому это ответственно за передачу битов режима open и Вы не получаете мнение в вопросе. install(1) значением по умолчанию копирует Ваш файл в новое местоположение и устанавливает выполнить биты, но этого все еще не происходит во время создания. –  Joseph R. 21.11.2013, 15:18
  • 3
    Что Вы говорите, это touch например, ответственно для устанавливания правильных значений. Вы знаете, где это хранит значения? Возможно, они установлены в масштабе всей системы - таким образом, мы могли изменить их? Поскольку я хочу вырваться на свободу ;) –  Peter 21.11.2013, 15:21
  • 4
    @PeterI Видит обновленный ответ. –  Joseph R. 21.11.2013, 15:27
  • 5
    @PeterI я обновил ответ снова. Вы можете делать syscall непосредственно или из C или из другого языка как Perl. –  Joseph R. 21.11.2013, 15:32

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

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

Однако много приложений создают файлы с полномочиями 0666. Это имеет две причины:

  1. Безопасность: Вы не хотите, чтобы любой произвольный файл был исполняемым файлом.
  2. Удобство: большинство файлов не должно быть исполняемым файлом. Легче установить исполняемый файл, обдумал выбор немного файлов, чем сбросить его на огромной сумме других файлов. Конечно, umask 0133 решил бы это, но затем ничто не выиграно, и Вы не могли позволить программам создать исполняемые файлы, даже если бы Вы хотели.
6
27.01.2020, 19:55
  • 1
    создаются без x (выполняют) набор битов из соображений безопасности. Непреднамеренное выполнение файлов [по часовой стрелке] ould быть "Плохой Вещью" (TM). chmod программа дает Вам способность к (ре) биты полномочий набора по мере необходимости. –  ChuckCottrill 22.11.2013, 02:02

Теги

Похожие вопросы