The Server Pages
:: TSP Menu
- Home
- Authors
- Glossary
- RSS Feed

:: Servers
- CPanel
- Hosting
- Linux
- Windows

:: Webmaster
- Databases
- Design
- Search Engines

:: Scripts
- Scripts

:: Documentation
- PHP Manual

:: Other
- Errors & Solutions
- TechPunt
- Wojjie

search for in the

unlink> <touch
[edit] Last updated: Sat, 12 May 2012

view this page in


(PHP 4, PHP 5)

umaskChanges the current umask


int umask ([ int $mask ] )

umask() sets PHP's umask to mask & 0777 and returns the old umask. When PHP is being used as a server module, the umask is restored when each request is finished.



The new umask.

Return Values

umask() without arguments simply returns the current umask otherwise the old umask is returned.


Example #1 umask() example


// Checking
if ($old != umask()) {
'An error occured while changing back the umask');



Avoid using this function in multithreaded webservers. It is better to change the file permissions with chmod() after creating the file. Using umask() can lead to unexpected behavior of concurrently running scripts and the webserver itself because they all use the same umask.

unlink> <touch
[edit] Last updated: Sat, 12 May 2012
add a note add a note User Contributed Notes umask
neon at neonjs dot com 30-Jul-2011 07:19
In case you don't understand why you need to "Avoid using this function in multithreaded webservers":

It's because this function changes the umask at the process level, rather than only for PHP or for the current script.  If there are multiple simultaneous threads running in the process in which your PHP script is running, the change will apply to all of those threads at the same time hence why this is not safe for multithreaded use.

I understand that if you are using the PHP module and Apache's prefork MPM, which is not multi-threaded, then you at least won't get race-condition problems such as this.  However, it is still worth noting that the umask setting, if not re-set, will persist for the life of that process even if the process is re-used to serve future PHP or non-PHP requests.
bishop 30-Sep-2010 06:01
"It is better to change the file permissions with chmod() after creating the file."

If you take that advice seriously, consider setting your umask so that files are created private to your user, then use chmod to open them up.

// files will create as -rw-------

// create a file, eg fopen()

// give access: -rw-r--r--
chmod('/path/to/file', 0644);

Whenever reasonable, default to shut and open as needed (like above) instead of default to open and shut as needed.  The above still has a race condition, but the race condition will deny appropriate access instead of granting inappropriate access.
webmaster at iacomputing dot co dot uk 28-Sep-2010 04:24
You can use umask to solve the PHP session bug that appears in several PHP versions.


This will prevent sessions being created with inadequate permissions.
librodot at ciberpiula dot net 17-Jun-2009 04:54
I think that the best way to understand umask is to say that umask is used to revoke permissions, not to set permissions.

umask sets which permissions must be removed from the system default when you create a file or a directory.

For example, a mask 0022 means that you don't want group and others modify the file.

default 0666
umask   0022 ---.-w-.-w-
Final   0644 rw-.r--.r--

That means that any file from now on will have 0644 permissions.

It is important to understand that umask revokes, deletes permissions from system default, so it canĀ“t grant permissions the system default hasn't. In the example above, with the 666 system default, there is no way you can use umask to create a file with execute permission. If you want to grant more permissions, use chmod.

Be aware that system default permissions are not related to PHP (they depends upon server configuration). PHP has a default umask that is applied after system default base permissions. And there are different system default base permissions for files and directories.

Usually, system default permissions for files are 666 and for directories 0777. And usually, default PHP umask is 0022
creccles at gmail dot com 27-Oct-2008 10:29
Understanding umask() properly is made more difficult for the novice programmer by the spurious flitting between UNIX's octal representation of file permissions and PHP's requirements for (decimal) integer arguments to most of its functions (including umask).
Instead of making mental pictures of chains of rwx|rwx|rw- type words and then tying yourself in cerebral knots manipulating them between the two different number systems, look at the issue as one involving simple bit patterns:
On most hosts, the baseline permission for created data files is the well-known OCTAL 0666, which means a bit pattern:  110110110.
The baseline pattern for new directories is OCTAL 0777, which is 111111111.
Both of these are subject to modification by the current system-wide umask setting, which is normally OCTAL 0022 or, bitwise:  000010010.
The mask works like this:

1. INVERT the binary umask
2. Perform an AND operation with the baseline permission pattern
3. Result is the bit pattern which will be applied to your new files or


System-wide umask:           000010010 (OCTAL 0022)

INVERTED:                    111101101
& with baseline:             110110110 (OCTAL 0666)
Result:                      110100100

... which is OCTAL 0644.

Let us say you want write permissions on files for your workgroup:

The bit pattern you are aiming for is:  110110100    (OCTAL 0664)

What needs to be AND-ed with our baseline 110110110 to give us this ?
Any AND relationship is reversible, so the answer is given by:

baseline:                    110110110 (OCTAL 0666)
target:                      110110100 (OCTAL 0664)
result:                      111110101

inversion gives:             000001010 (OCTAL 0012)

... which is our desired umask.

Lining up bits in a binary AND is conceptually easier than juggling
with the rw-rwx--x notation when it comes to masks.  Remember that
an AND only delivers a binary '1' when a binary '1' is present in BOTH

Always pass this to PHP in the form:


... so that the umask() function receives a true INT type.
jphansen at uga dot edu 04-Mar-2008 06:45
On most UNIX environments the recommended default umask for files, defined in /home/user/.profile or /etc/profile, is 022 (chmod: 644). On trusted systems it is 002. Exercise caution when applying more liberal settings.
maulwuff at gmx dot de 18-Sep-2007 03:44
umask takes away the given values from the standard mask 777.
A graphical view shows this better:

rwxrwxrwx = 777
will get with umask 002:
rwxrwxr-x  = 775
or will get with umask 077:
rwx------ = 700

and so on.
sean at awesomeplay dot com 30-May-2007 09:48
"It is better to change the file permissions with chmod() after creating the file."

The usual lacking of security knowledge within the PHP team rears its head once again.  You *always* want to have the file created with the proper permission.  Let me illustrate why:

(a) you create new file with read permissions
(b) an attacking script opens the file
(c) you chmod the file to remove read permissions
(d) you write sensitive data to the file

Now, you might think that the changes of an attacking script getting to open the file before you chmod them are low.  And you're right.  But low changes are never low enough - you want zero chance.

When creating a file that needs increased permissions, you always need to create the file with the proper permissions, and also create it with O_EXCL set.  If you don't do an exclusive create, you end up with this scenario:

(a) attacker creates the file, makes it writable to everyone
(b) you open the file with restricted permissions, but since it already exists, the file is merely opened and the permissions left alone
(c) you write sensitive data into the insecure file

Detecting the latter scenario is possible, but it requires a bit of work.  You have to check that the file's owner and group match the script's (that is, posix_geteuid(), not myuid()) and check the permissions - if any of those are incorrect, then the file is insecure - you can attempt to unlink() it and try again while logging a warning, of course.

The only time when it is reasonable or safe to chmod() a file after creating it is when you want to grant extra permissions instead of removing them.  For example, it is completely safe to set the umask to 0077 and then chmoding the files you create afterward.

Doing truly secure programming in PHP is difficult as is, and advice like this in the documentation just makes things worse.  Remember, kids, anything that applies to security in the C or UNIX worlds is 100% applicable to PHP.  The best thing you can possibly do for yourself as a PHP programmer is to learn and understand secure C and UNIX programming techniques.
ShaD@TW 16-May-2006 09:32
Notice that directory(s) and file(s) sometimes have different results.

(0670);                    //- set umask
$handle = fopen('file', 'w');   //- 0006
mkdir("/path/dir");             //- 0107

calculate the result:
= 0670;
//- if you are creating a new directory, $permission = 0777;
//- if you are creating a new file, $permission = 0666.
printf( "result: %04o", $permission & ( 0777 - $umask) );

BTW, as the manual said, the form of umask() is "int umask ( [int mask] )", so if you want to print/echo any umask, don't forget to convert it from DEC (because it returns a "int") to OCT.

= umask();          //- returns the current umask, which is a "int"
$umask = decoct($umask);   //- Now, $umask is a "string"
echo $umask;

Don't forget that the argument(parameter) is a "int", too.

(777);    //- WRONG! Even though you maybe use "umask 777" in some OS.
umask(0777);   //- OK

If there was any mistake, please correct my statement.
18-Feb-2006 08:31
Using (cmask - umask) is a wrong way to calculate the new mask:

0022 - 0700 = 0656 WRONG
0700 & ~0022 = 0700 CORRECT

Correct php code:
= ($cmask & ~$umask);
andi<at> 03-Mar-2005 02:03
To play around with umasks and permissions use this little fragment:

= 0012;
$perm  = 0777;
printf("umask: %04o perm: %04o result: %04o\n",
$umask,$perm,$perm & (0777 - $umask));
trisk at earthling dot net 31-Jan-2005 09:25
I thought I would clarify the numbering scheme used here, as it confused me at first.

On the UNIX console, the command:

umask "blah"

In this instance, the umask command forces "blah" to be an octal number, regardless of how many digits you use and regardless of any leading zeroes.  In PHP, umask() does not default to octal as the console command does, it uses whatever numeric format you specify.

For example:


This uses the decimal integer 213 and not the octal number 213 as you would expect when using the console command.  In this case, it would set the umask to the octal number "325".

To enter the number as octal, just add one or more zeroes to the left of the number:


sam at totallydigital dot co dot nz 19-Sep-2002 09:04
The first comment perhaps didn't quite make clear what's on with your umask and the permissions.

The permission passed to a command is first bitwise ANDed with the _INVERSE_ of the current umask, then applied to the file.

For example, umask = 0011 and permission = 0775
The inverse of 0011 = 0766

0775 AND 0766
= 111.111.101 AND 111.110.110
= 111.110.100
= 0764

show source | credits | sitemap | contact | advertising | mirror sites