I\'m trying to set a umask using the os module. Please note my normal umask set in my ~/.profile is umask 0027.
In a bash shell,
umask 0022
Being picky/careful, and Python 3k-compatible, here is my slightly different answer (that still doesn't explain what the OP's original issue was):
old_umask = os.umask(0o022) # u=rwx,g=rx,o=rx
try:
# do stuff
finally:
os.umask(old_umask)
Misunderstanding of umask, I think. The umask sets the default denials, not the default permissions. So
import os
oldmask = os.umask (0o22)
fh1 = os.open ("qq1.junk", os.O_CREAT, 0o777)
fh2 = os.open ("qq2.junk", os.O_CREAT, 0o022)
os.umask (oldmask)
os.close (fh1)
os.close (fh2)
should indeed produce files as follows:
-rwxr-xr-x 1 pax pax 0 Apr 24 11:11 qq1.junk
---------- 1 pax pax 0 Apr 24 11:11 qq2.junk
The umask 022 removes write access for group and others, which is exactly the behaviour we see there. I find it helps to go back to the binary that the octal numbers represent:
usr grp others
-rwx rwx rwx is represented in octal as 0777, requested for qq1.junk
-000 010 010 umask of 022 removes any permission where there is a 1
-rwx r-x r-x is the result achieved requesting 0777 with umask of 022
---- -w- -w- is represented in octal as 0022, requested for qq2.junk
-000 010 010 umask of 022 removes any permission where there is a 1
---- --- --- is the result achieved requesting 0022 with umask of 022
The program is behaving as you asked it to, not necessarily as you thought it should. Common situation, that, with computers :-)
Even though this would seem to be a straight system call, in this case it does seems to matter what Python version you are using:
It appears that os.open handles the pre-existing umask differently in Python 2.x and Python 3.x, possibly because 2.x is closer to the OS and 3.x does a bit more abstraction.
https://docs.python.org/2/library/os.html "The default mode is 0777 (octal), and the current umask value is first masked out."
There is no similar statement in https://docs.python.org/3/library/os.html
You'll probably need to show us the code that constitutes:
[do some other code here that creates a file]
The code you have works fine on my system:
import os
oldmask = os.umask (022)
fh1 = os.open ("qq1.junk", os.O_CREAT, 0777)
fh2 = os.open ("qq2.junk", os.O_CREAT, 0022)
os.umask (oldmask)
os.close (fh1)
os.close (fh2)
producing files as follows:
-rwxr-xr-x 1 pax pax 0 Apr 24 11:11 qq1.junk
---------- 1 pax pax 0 Apr 24 11:11 qq2.junk
You should also note the restoration of the old umask
value which minimises the impact of changing it to the local operation.
As you can see from the results above, you also need to be aware that the umask
value is "subtracted" from the mode you're using to create the file and we don't know what that mode is in your particular case.
That's evident even in your bash
sample since a umask
value of 022
when creating a file of mode 777
would result in r-xr-xr-x
, not rw-r--r--
as you have it.
Based on your comments below where you indicate you're using open
rather than os.open
, a cursory glance of the Python source seems to indicate that this translates to a C fopen
call which uses 0666
as the initial mode. This is supported by the slightly modified code:
import os
oldmask = os.umask (022)
fh3 = open ("qq3.junk", "w")
os.umask (0)
fh4 = open ("qq4.junk", "w")
os.umask (oldmask)
fh3.close()
fh4.close()
which gives us:
-rw-r--r-- 1 pax pax 0 Apr 24 11:44 qq3.junk
-rw-rw-rw- 1 pax pax 0 Apr 24 11:44 qq4.junk
So I'm not entirely certain why you're getting 0000
permissions in your case.
It would be worth seeing what the results are when you run that above program in your environment. If it's the same as I get then the problem may well lie somewhere else.