possible security issue

[Ben Finney]

On 22-Jul-2014, Michael Hrivnak wrote:
> With great respect to the Stevens reference, it should not be
> followed blindly.

I don't wish anyone to follow anything blindly. Why do you say that?
The Stevens reference gives a good rationale for setting umask to 0.

If you know of a more authoritative reference for the details of how a
program should become a well-behaved Unix daemon, I'm open to learn.

Until then, meeting the promise of implementing a well-behaved Unix
daemon entails following the specifics of the Stevens description,
where feasible. I don't consider it acceptable to violate that promise.

> I think Ian has nailed the important issue, that python's
> limitations make safe behavior difficult to implement with a umask
> of 0.

The Stevens reference gives a good rationale. What alternative value
has a better specific rationale? What is that rationale?

> Running any python process with a umask of 0 makes common builtins
> and parts of the standard library unsafe.

Yes, this puts the onus on the implementor of the daemon to make a
deliberate decision to set a specific umask value.

For now I'm inclined to update the ‘python-daemon’ documentation on
why and how to do that.

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

That's laudable. Where there is ambiguity, though, Python also has a
strong culture of refusing the temptation to guess what is meant.

-- 
 \       “Repetition leads to boredom, boredom to horrifying mistakes, |
  `\       horrifying mistakes to God-I-wish-I-was-still-bored, and it |
_o__)              goes downhill from there.” —Will Larson, 2008-11-04 |
Ben Finney <ben at benfinney.id.au>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/python-daemon-devel/attachments/20140723/f1884c30/attachment.sig>