Delicious Bookmark this on Delicious Share on Facebook SlashdotSlashdot It! Digg! Digg



PHP : Function Reference : Filesystem Functions : umask

umask

Changes the current umask (PHP 4, PHP 5)
int umask ( [int mask] )

Example 673. umask() example

<?php
$old
= umask(0);
chmod("/path/some_dir/some_file.txt", 0755);
umask($old);

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

Code Examples / Notes » umask

18-feb-2006 04:31

Using (cmask - umask) is a wrong way to calculate the new mask:
0022 - 0700 = 0656 WRONG
0700 & ~0022 = 0700 CORRECT
Correct php code:
<?php
$rmask = ($cmask & ~$umask);
?>


maulwuff

umask takes away the given values from the standard mask 777.
A graphical view shows this better:
standard:
rwxrwxrwx = 777
will get with umask 002:
rwxrwxr-x  = 775
or will get with umask 077:
rwx------ = 700
and so on.


andisplitbrain.org

To play around with umasks and permissions use this little fragment:
<?
$umask = 0012;
$perm  = 0777;
printf("umask: %04o perm: %04o result: %04o\n",
      $umask,$perm,$perm & (0777 - $umask));
?>


sam

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


shad@tw

Notice that directory(s) and file(s) sometimes have different results.
<?php
umask(0670);                    //- set umask
$handle = fopen('file', 'w');   //- 0006
mkdir("/path/dir");             //- 0107
?>
calculate the result:
<?php
$umask = 0670;
umask($umask);
//- 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.
<?php
$umask = 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.
<?php
umask(777);    //- WRONG! Even though you maybe use "umask 777" in some OS.
umask(0777);   //- OK
?>
If there was any mistake, please correct my statement.


trisk

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:
umask(213);
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:
umask(0213);
umask(07);
umask(0044);
etc.


sean

"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.


Change Language


Follow Navioo On Twitter
basename
chgrp
chmod
chown
clearstatcache
copy
delete
dirname
disk_free_space
disk_total_space
diskfreespace
fclose
feof
fflush
fgetc
fgetcsv
fgets
fgetss
file_exists
file_get_contents
file_put_contents
file
fileatime
filectime
filegroup
fileinode
filemtime
fileowner
fileperms
filesize
filetype
flock
fnmatch
fopen
fpassthru
fputcsv
fputs
fread
fscanf
fseek
fstat
ftell
ftruncate
fwrite
glob
is_dir
is_executable
is_file
is_link
is_readable
is_uploaded_file
is_writable
is_writeable
lchgrp
lchown
link
linkinfo
lstat
mkdir
move_uploaded_file
parse_ini_file
pathinfo
pclose
popen
readfile
readlink
realpath
rename
rewind
rmdir
set_file_buffer
stat
symlink
tempnam
tmpfile
touch
umask
unlink
eXTReMe Tracker