Php umask() function
Содержание:
How are permissions represented?
There are two ways to represent a file’s permissions: symbolically (using symbols like «r» for read, «w» for write, and «x» for execute) or with an octal numeric value.
For example, when you list the contents of a directory at the command line using the ls command as follows:
ls -l
you will see (among other information) the file permission information for each file. Here, it is represented symbolically, which will look like the following example:
-rwxr-xr--
There are ten symbols here. The first dash («—«) means that this is a «regular» file, in other words, not a directory (or a device, or any other special kind of file). The remaining nine symbols represent the permissions: rwxr-xr—. These nine symbols are actually three sets of three symbols each, and represent the respective specific permissions, from left to right:
| symbols | meaning |
|---|---|
| rwx | the file’s owner may read, write, or execute this file as a process on the system. |
| r-x | anyone in the file’s group may read or execute this file, but not write to it. |
| r— | anyone at all may read this file, but not write to it or execute its contents as a process. |
What are permissions, and how do they work?
As you may know, each file on your system has associated with it a set of permissions that are used to protect files: a file’s permissions determine which users may access that file, and what type of access they have to it.
There are three general classes of users:
- The user who owns the file («User«).
- Users belonging to the file’s defined ownership group («Group«).
- Everyone else («Other«).
In turn, for each of these classes of user, there are three types of file access:
- The ability to look at the contents of the file («Read«).
- The ability to change the contents of the file («Write«).
- The ability to run the contents of the file as a program on the system («Execute«).
So, for each of the three classes of user, there are three types of access. Taken together, this information makes up the file’s permissions.
Specifying the file creation mask using numeric representation
The file creation mask can also be represented numerically, using octal values (the digits from 0 to 7). When using octal numeric representation, certain numbers represent certain permissions, and these numbers are added or subtracted from each other to represent the final, combined permissions value. Specifically, the numbers 1, 2, and 4 represent the following permissions:
| number | permission |
|---|---|
| 4 | read |
| 2 | write |
| 1 | execute |
These numbers are used because any combination of these three numbers will be unique. The following table illustrates their unique combinations:
| read value + | write value + | execute value = | combined value: | symbolic equivalent: |
|---|---|---|---|---|
| 1 | 1 | x | ||
| 2 | 2 | w | ||
| 2 | 1 | 3 | wx | |
| 4 | 4 | r | ||
| 4 | 1 | 5 | rx | |
| 4 | 2 | 6 | rw | |
| 4 | 2 | 1 | 7 | rwx |
For each class of user, one digit can be used to represent their permissions; using the example above, we could represent the symbolic permission of rwxr-xr— using the three-digit octal number 754. The order of the digits is always the same: User, Group, Other.
A Word of Caution
An important point to remember when changing permissions is that certain areas of the filesystem and certain processes require specific permissions to run correctly. Inadequate permissions can lead to errors and non-functioning applications.
On the other hand, settings that are too permissive can be a security risk.
For these reasons, it is recommended that you do not adjust permissions outside of your own home directory unless you are aware of the repercussions that can arise due to improperly configured settings.
Another good rule to abide by, especially when configuring software manually, is to always assign the most restrictive permissions policy possible without affecting functionality.
This means that if only one user (such as a service) needs to access a group of files, then there is no need to allow the rest of the world to have write or even read access to the contents. This is especially true in contexts where passwords are stored in plain-text.
You can fine-tune permissions more fully by correctly utilizing group owner permissions and adding necessary users to the appropriate group. If all of the users who need access to a file are members of the group owner, then the other permission category can be locked down for more security.
By Justin Ellingwood
Dış bağlantılar
| Unix komutları (daha fazla) | |
| Dosya dizgesi | cat • cd • chmod • chgrp • chown • cksum • cmp • cp • dd • du • df • fsck • fuser • ln • ls • lsattr • lsof • mkdir • mount • mv • pwd • rm • rmdir • split • touch • umask |
| Süreç ve görev yönetimi | at • chroot • cron • crontab • exit • kill • killall • nice • pgrep • pidof • pkill • ps • pstree • sleep • time • top • wait |
| Kullanıcı ortamı | env • finger • id • logname • mesg • passwd • su • sudo • uptime • w • wall • who • whoami • write |
| Metin işleme | awk • comm • csplit • cut • diff • ed • ex • fmt • head • iconv • join • less • more • paste • sed • sort • strings • tail • talk • tr • uniq • vi • vim • wc • xargs |
| Kabuk programlama | alias • basename • dirname • echo • expr • false • printf • test • true • unset |
| Ağ Araçları | inetd • host • ifconfig • netcat • netstat • nslookup • ping • rlogin • traceroute |
| Arama | find • grep • locate • whereis • which |
| Diğer | apropos • banner • bc • cal • clear • date • dd • file • help • history • info • lp • lpr • man • pax •size • tee • tput • type • uname • whatis • yes |
Общие понятия:
У каждого объекта в Linux есть свой идентификатор, а так же права доступа, применяемые к данному идентификатору. Идентификатор есть у пользователя — UID, у группы — GID, у файла — inod. Собственно inode является, как идентификатором файла/каталога, так и сущностью, которая содержит в себе информацию о файле/каталоге. Например такую, как: принадлежность к владельцу/группе, тип файла и права доступа к файлу.
Чтобы визуально лицезреть права доступа к файлу или каталогу, его тип и владельцев, а так же, если необходимо, и сам номер inode, необходимо выполнить следующую команду:
Print-server:/# ls -li итого 50 22089 drwxr-xr-x 2 root root 3072 Ноя 15 14:15 bin 32129 drwxr-xr-x 3 root root 1024 Окт 1 18:03 boot 12 lrwxrwxrwx 1 root root 11 Окт 1 15:36 cdrom -> media/cdrom 557 drwxr-xr-x 13 root root 3340 Ноя 17 06:25 dev 30121 drwxr-xr-x 50 root root 4096 Ноя 15 14:46 etc ....
Из вывода команды видно (рассмотрим первую строку):
22089
это есть номер inode
drwxr-xr-x
это есть те самые права доступа и тип файла (об этом ниже)
2
количество жестких ссылок на файл
root
имя владельца файла
root
имя группы владельца файла
3072
размер файла
Ноя 15 14:15
дата создания файла
bin
имя файла/каталога
Для каждого объекта файловой системы в модели полномочий Linux есть три типа полномочий: полномочия чтения (r от read), записи (w от write) и выполнения (x от execution). В полномочия записи входят также возможности удаления и изменения объекта. Право выполнения можно установить для любого файла. Потенциально, любой файл в системе можно запустить на выполнение, как программу в Windows. В Linux является ли файл исполняемым или нет, определяется не по его расширению, а по правам доступа. Кроме того, эти полномочия указываются отдельно для владельца файла, членов группы файла и для всех остальных.
Собрав вышесказанное в кучу, то есть представив 3 правила (rwx) для трех групп (владелец, группа, остальные) запись прав доступа будет выглядеть вот так: rwx rwx rwx(то есть владельцу разрешено чтение, выполнение и запись, группе разрешено то же самое и остальным). Рассмотрев права на папку /bin в выше приведенном листинге, можно представить такую картину:
drwxr-xr-x+ ||||||||||+наличие дополнительных прав (ACL) |||||||||+-исполнение для всех остальных - разрешено ||||||||+--запись для всех остальных - НЕ разрешено |||||||+---чтение для всех остальных - разрешено ||||||+----исполнение для группы владельца - разрешено |||||+-----запись для группы владельца - НЕ разрешено ||||+------чтение для группы владельца - разрешено |||+-------исполнение для владельца - разрешено ||+--------запись для владельца - разрешено |+---------чтение для владельца - разрешено +----------тип файла (об этом ниже...)
Кроме указанного представления полномочий доступа (символьного), существует так же и числовое представление. Для общего понимания, приведу таблицу соответствия числового (двоичного и десятичного) значения прав доступа и буквенного:
| владелец | группа | остальные | |
| буквенное | rwx | r-x | r— |
| числовое (десятичное) | 421 | 401 | 400 |
| итоговое | 7 | 5 | 4 |
В приведенной таблице показано, что право чтения, соответствует значению 4, право записи — 2, право выполнения — 1, отсутствие права — 0, складывая данные показатели, можно представлять и назначать права в числовом виде. Для примера, права rwx r-x r— будут соответствовать значению 754, потому что: rwx (4+2+1=7) r-x (4+0+1=5) r— (4+0+0=4). Так же, довольно распространена комбинация rw- (4+2+0=6). Думаю данный пример достаточно нагляден.
5 ответов
umask действует как ряд полномочий, которые приложения не могут установить на файлах. Это — маска создания режима файла для процессов и не может быть установлено для каталогов сама. Большинство приложений не создало бы файлы с, выполняют набор полномочий, таким образом, у них было бы значение по умолчанию , который затем изменяется umask.
Поскольку Вы установили umask для удаления битов чтения-записи для владельца и битов чтения для других, значение по умолчанию такой как в приложениях привел бы к файлу полномочиям тому, чтобы быть . Это означало бы, что Вы (и другие) могли выполнить файл, и другие смогут записать в него.
Если Вы хотите к make-файлам не, читаются/пишутся/выполняются любым, но владельцем, необходимо использовать umask как выключить те полномочия для группы и других.
Напротив, umask сделает недавно созданные каталоги читаемыми, перезаписываемыми, и передаваемый по наследству для всех (полномочия будут ). Такой umask очень небезопасен, и Вы никогда не должны устанавливать umask на .
Значение по умолчанию umask на Ubuntu было что означает, что недавно созданные файлы читаемы всеми, но только перезаписываемы владельцем:
При запуске в Ubuntu, Сновещательной (11.10), значение по умолчанию umask было ослаблено к , который разворачивает доступ для записи к группе владельца:
Просмотр и изменение umask
Для просмотра текущей установки umask откройте терминал и выполните команду:
Для изменения umask настроек текущей оболочки к чему-то еще скажите 077, работайте:
Чтобы протестировать, работает ли эта установка или нет, можно создать новый файл (полномочия файла существующего файла не будут затронуты), и покажите информацию о файле, работайте:
Установка umask наследована процессами, запущенными с той же оболочки. Например, запустите текстовый редактор GEdit путем выполнения в терминале и сохранили файл с помощью gedit. Вы заметите, что недавно созданный файл затронут тем же umask, устанавливающим как в терминале.
Вариант использования: многопользовательская система
Если Вы находитесь в системе, это совместно используется многочисленными пользователями, желательно, чтобы другие не могли считать файлы в Вашем корневом каталоге. Для этого umask очень полезен.Править и добавьте новую строку с:
Необходимо повторно войти в систему для этого изменения umask в вступить в силу. Затем, необходимо изменить существующие полномочия файла файлов в корневом каталоге путем удаления чтения, записать и выполнить бит для мира. Откройте терминал и выполнитесь:
Если Вы хотите этот umask, устанавливающий, применяются ко всем пользователям в системе, Вы могли отредактировать файл профиля в масштабе всей системы в .
ответ дан
22 November 2019 в 22:46
В дополнение к хорошему обсуждению в принятом ответе стоит добавить еще некоторые точки о , со ссылкой на то, как этим управляют в 12,04 и вперед.
Umask и pam_umask
Значение по умолчанию umask находится теперь в а не в , как официальное примечание в чтения:
кратко объяснен ниже, и нужно сказать, что файл по умолчанию для пользователя для размещения его пользовательского начинающегося umask тих .
один из многих важных модулей PAM, которые крайне важны для операции Ubuntu (выполненный найти страницы справочника для других). В странице справочника для это отмечено это
Примечание по значению по умолчанию umask
Новые папки в может быть создан со значением по умолчанию 775 полномочий и файлы, созданные с со значением по умолчанию 664 полномочий, даже когда значение по умолчанию umask равняется 022. Это кажется, сначала, противоречащим, и стоит объяснить.
В то время как значение по умолчанию umask 022 на Ubuntu, это не целая история, поскольку существует установка в это позволяет umask быть 002 для некорневых пользователей, если условие соблюдают (см. выборку ниже). На нормальной установке, содержит установку . Это что
Следовательно, почему Вы видите следующее с когда новая папка создается с в системе отдельного пользователя такой как мой (uid и ценуроз то же):
Для получения дополнительной информации посмотрите и страницы справочника Ubuntu онлайн.
ответ дан
22 November 2019 в 22:46
Это довольно старо, но это стоит упомянуть. Вычислять для umask, в отличие от полномочий файловой системы. Восьмеричные umasks вычисляются через поразрядное И унарного дополнения аргумента с помощью битового «НЕ». Восьмеричные нотации следующие:
Затем можно вычислить для установки umask надлежащих предварительных миссий такой:
Вычисление заключительного разрешения для файлов
Можно просто вычесть umask из основных полномочий определить заключительное разрешение для файла следующим образом:
- Полномочия основы файла:
- значение umask:
- вычтите для получения полномочий нового файла :
DESCRIPTION top
umask() sets the calling process's file mode creation mask (umask) to
mask & 0777 (i.e., only the file permission bits of mask are used),
and returns the previous value of the mask.
The umask is used by open(2), mkdir(2), and other system calls that
create files to modify the permissions placed on newly created files
or directories. Specifically, permissions in the umask are turned
off from the mode argument to open(2) and mkdir(2).
Alternatively, if the parent directory has a default ACL (see
acl(5)), the umask is ignored, the default ACL is inherited, the
permission bits are set based on the inherited ACL, and permission
bits absent in the mode argument are turned off. For example, the
following default ACL is equivalent to a umask of 022:
u::rwx,g::r-x,o::r-x
Combining the effect of this default ACL with a mode argument of 0666
(rw-rw-rw-), the resulting file permissions would be 0644 (rw-
r--r--).
The constants that should be used to specify mask are described in
inode(7).
The typical default value for the process umask is S_IWGRP | S_IWOTH
(octal 022). In the usual case where the mode argument to open(2) is
specified as:
S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH
(octal 0666) when creating a new file, the permissions on the result‐
ing file will be:
S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH
(because 0666 & ~022 = 0644; i.e., rw-r--r--).
DESCRIPTION top
The umask utility shall set the file mode creation mask of the
current shell execution environment (see Section 2.12, Shell
Execution Environment) to the value specified by the mask operand.
This mask shall affect the initial value of the file permission bits
of subsequently created files. If umask is called in a subshell or
separate utility execution environment, such as one of the following:
(umask 002)
nohup umask ...
find . −exec umask ... \;
it shall not affect the file mode creation mask of the caller's
environment.
If the mask operand is not specified, the umask utility shall write
to standard output the value of the file mode creation mask of the
invoking process.
NOTES top
A child process created via fork(2) inherits its parent's umask. The
umask is left unchanged by execve(2).
It is impossible to use umask() to fetch a process's umask without at
the same time changing it. A second call to umask() would then be
needed to restore the umask. The nonatomicity of these two steps
provides the potential for races in multithreaded programs.
Since Linux 4.7, the umask of any process can be viewed via the Umask
field of /proc//status. Inspecting this field in
/proc/self/status allows a process to retrieve its umask without at
the same time changing it.
The umask setting also affects the permissions assigned to POSIX IPC
objects (mq_open(3), sem_open(3), shm_open(3)), FIFOs (mkfifo(3)),
and UNIX domain sockets (unix(7)) created by the process. The umask
does not affect the permissions assigned to System V IPC objects
created by the process (using msgget(2), semget(2), shmget(2)).
