Explicit advice to choose a secure umask

[Ben Finney]

On 01-Aug-2014, Ethan Furman wrote:
> It is certainly better than the status quo, but I must admit I don't
> understand why you place more importance on following a now
> known-to-be-insecure default rather than going with a
> secure-by-default design.

The default of “set the umask to 0” was always known to produce an
insecure program; that's exactly why there is a parameter to set an
explicitly-chosen umask value as chosen by the daemon programmer.

The default of 0 is because there is no unambiguous, obvious single
value to set instead. The reason given in the Stevens reference is
because the programmer is assumed to know better than the library what
mode to create files with.

> If a daemon user needs world-writable files it is not hard to change
> the daemon umask setting to 0, but by having it be something else,
> such as 077

There's no single umask value which makes sense by default. If you
know of one, I will need more than anecdote or personal preference, I
will need to see substantial evidence in favour of daemon programmers,
on all Unix variants Python supports, expecting *one specific*
behaviour over all others.

Moreover, “set the umask to 0 and let the specific daemon program
decide for itself” is the conventional behaviour for Unix daemons
everywhere I've seen. We're implementing conventional behaviour for
Unix daemons.

So that's a strong reason not to deviate from that without a clearly
better setting — and “something else, such as foo” is not a clear
mandate for that specific value.

> then all who are ignorant of the trap still won't fall into it

So the best I can get from that is that you'd prefer no default, and
instead raise an exception if no umask value is specified. Yes?

-- 
 \       “If you go flying back through time and you see somebody else |
  `\   flying forward into the future, it's probably best to avoid eye |
_o__)                                           contact.” —Jack Handey |
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/20140801/5edd4280/attachment-0001.sig>