possible security issue

Michael Hrivnak mhrivnak at redhat.com
Tue Jul 22 14:06:21 UTC 2014


With great respect to the Stevens reference, it should not be followed blindly. I think Ian has nailed the important issue, that python's limitations make safe behavior difficult to implement with a umask of 0.

Running any python process with a umask of 0 makes common builtins and parts of the standard library unsafe. For example, "open(filename, 'w')" will always create a world-writable file. It is then up to the software to go back and change the permissions to something sane, which leaves a window of opportunity during which the file is not secure. That window of insecurity is not acceptable.

Or if a developer calls "os.makedir" without specifying a mode, which I bet is not uncommon, they will create a world-writable directory without realizing it. A reasonable argument can be made that developers should be explicit about file modes when possible, but there is also great value in having a safe default.

While everyone expects that writing in C requires you to think about and manage every little detail of your application's behavior, python has more of a culture where people expect things to "just work". Regardless of whether you consider that good or bad, I think that cultural difference means that a lot of python devs expect that they can create files and directories with a safe default behavior. Also consider python's heavy use as a scripting language, which has a large portion of the community approaching python development from a very different mindset. For better or worse, I bet a lot of people call functions like "os.makedir" without specifying a mode. Changing the umask to 0 by default puts their applications at risk.

Having stated my case, since I'm not actually using python-daemon, I'm happy to let you exercise your best judgement about how it should behave. The celery project (which I am using) has already adjusted its default behavior, so it no longer changes the umask unless one is specified.

Michael


----- Original Message -----
From: "Ian Zimmerman" <ian.zimmerman at linqia.com>
To: python-daemon-devel at lists.alioth.debian.org
Sent: Wednesday, July 16, 2014 10:57:38 AM
Subject: Re: possible security issue



There may be a difference between daemons coded in C and Python. In C, it is trivial for the programmer to force fixed mode flags when opening files that may not exist - by supplying the 3rd argument to open() . In Python one would have to drop to OS specific code to do that - in fact I cannot remember the spelling OTTOMH. 
On Jul 15, 2014 9:35 PM, "Ben Finney" < ben+python at benfinney.id.au > wrote: 


On 15-Jul-2014, Michael Hrivnak wrote: 

> The summary is that worker daemon processes in celery by default 
> will change their umask to 0. Then if they create new files, those 
> files will be world-writable. Looking at PEP 3143, it seems that 
> python-daemon may also have a default umask of 0. 

Yes, this is a specific mandate from the primary source for standard 
Unix daemon behaviour. As cited in PEP 3143, the library follows “Unix 
Network Programming”, W. Richard Stevens, 1994 Prentice Hall. Section 
2.6 of that book details the behaviour a properly-behaving Unix daemon 
should execute. 

In particular: 

Reset the File Access Creation Mask 

A process inherits its file access creation mask from its parent. 
A daemon should execute: 

umask(0); 

to reset this mask. This prevents any files created by the daemon 
from having their access bits modified. … 

> Zero is is not a safe or expected default. 

It is the only expected default I know of; the Stevens book is the 
canonical source for expected behaviour of Unix daemons, AFAIK. 

> The safe default is for a process to not change its inherited umask 
> unless explicitly directed to do so. Having a setting to change it 
> is fine, but the default behavior should be "no change". 

That would contradict the standard reference text, as far as I can see. 

> The impact of this behavior is that unless a user knows to 
> explicitly set a safe umask on their daemon processes, they could 
> end up with world-writable files without realizing it. 

I can modify the documentation to make clear that this is standard 
behaviour. Can you suggest wording? 

-- 
\ “At my lemonade stand I used to give the first glass away free | 
`\ and charge five dollars for the second glass. The refill | 
_o__) contained the antidote.” —Emo Philips | 
Ben Finney < ben at benfinney.id.au > 

_______________________________________________ 
python-daemon-devel mailing list 
python-daemon-devel at lists.alioth.debian.org 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-daemon-devel 


_______________________________________________
python-daemon-devel mailing list
python-daemon-devel at lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-daemon-devel



More information about the python-daemon-devel mailing list