Before understanding umask
, you should understand the permissions of the filesystem of * nix systems, some answers in the posts here may help:
What are the risks of using 777 permission?
Permission denied when moving file with move_upload_file on Linux server
Similarly,
umask
is a concept that makes sense in * nix systems, it's a PHP compatibility layer that uses existing filesystem resources (like many other libs are, some for DB, others for Web requests, etc.) that are independent of the page server.
Warning: When writing a number in PHP (and some other languages) prefixed by 0, this is an OCTAL number and not a decimal number. * Nix permissions are octal in nature (three bits per digit).
What's the use?
The name somehow already says: U be file creation M ask. It is a mask that is applied on top of the file permissions.
It basically removes privileges from the running process, denying them through a bitmask.
PHP defaults to umask
value 022, and this can be "loosened" if you decrease this value.
How does it work?
Example of the PHP manual itself:
original 0666 rw-.rw-.rw-
umask 0022 ---.-w-.-w-
final 0644 rw-.r--.r--
Seeing in binary to facilitate:
original 000 110 110 110 rw-.rw-.rw-
umask 000 000 010 010 ---.-w-.-w-
final 000 110 100 100 rw-.r--.r--
That is, umask
denied bits "2" of both other
and group
.
In practice, since the file creation pattern in the filesystem is 0666
and 0777
directories, the default 022
of umask
of PHP ends by setting this as default:
Note that umask
itself is already "masked", it gets a or
with 0777
before it is applied, so if it does umask( 01771 )
it will be worth as umask ( 0771 )
only .
It has an important detail when we use umask
, it returns the current value of the mask, regardless of whether you are creating a new one or just consulting, which brings us to the next point ...
The status of umask
at the end of the process:
In the manual we have this:
When PHP is being used as a server module, the umask is restored at the end of each request.
We have to remember that when you run PHP as CGI, you have multiple processes being created and released at the end, and when you run as a module, it is a continuous "procession". So what matters is not the "list" of used page servers, but rather the way PHP is run to determine whether umask
is reset at the end automatically or not.
Summary: Because the reset of umask
are very specific, and since you should not depend on the state of a script for the entire session, store the return of the first umask
you do and always reset the umask
to the default state at the end. Even better? Do not move if you have no real reason for it. Set what should be in the server configuration, and leave it. It is an option that can cause a lot of headaches if you do not have * nix permissions on the domain, and if you do, you probably do not even need that warning here.
Manual
link