Fix for Samba server masking world writeable perm off

[Alexander Bokovoy]

On ti, 26 helmi 2019, Rowland Penny via samba-technical wrote:
> On Tue, 26 Feb 2019 08:45:15 -0800
> Jeremy Allison <jra at samba.org> wrote:
> 
> > On Tue, Feb 26, 2019 at 04:44:21PM +0000, Rowland Penny via
> > samba-technical wrote:
> > > On Tue, 26 Feb 2019 18:31:55 +0200
> > > Alexander Bokovoy via samba-technical
> > > <samba-technical at lists.samba.org> wrote:
> > > 
> > > > On ti, 26 helmi 2019, Jeremy Allison via samba-technical wrote:
> > > > > On Tue, Feb 26, 2019 at 06:11:20PM +0200, Alexander Bokovoy
> > > > > wrote:
> > > > > > > 
> > > > > > > Is it possible some of the pam calls are setting a
> > > > > > > umask internally ?
> > > > > > Yes, most likely session phase is setting them -- either in
> > > > > > pam_limits or in pam_systemd.
> > > > > 
> > > > > Hmmm. Should we then explicitly set umask(0) after
> > > > > making the pam session calls ? It's setting the
> > > > > umask for smbd which is unwanted.
> > > > My understanding is that this is indeed a valid approach. At
> > > > least, manual page daemon(7) (from systemd suite) states for SysV
> > > > daemons:
> > > > 
> > > >        10. In the daemon process, reset the umask to 0, so that
> > > > the file modes passed to open(), mkdir() and suchlike directly
> > > > control the access mode of the created files and directories.
> > > > 
> > > > Further, it states for new-style daemons (integrated with
> > > > systemd):
> > > > 
> > > >        Note that new-style init systems guarantee execution of
> > > > daemon processes in a clean process context: it is guaranteed
> > > > that the environment block is sanitized, that the signal handlers
> > > > and mask is reset and that no left-over file descriptors are
> > > > passed.
> > > > 
> > > >        Daemons will be executed in their own session, with
> > > > standard input connected to /dev/null and standard output/error
> > > > connected to the systemd-journald.service(8) logging service,
> > > > unless otherwise configured. The umask is reset.
> > > > 
> > > > So, the expectation is that a daemon has umask reset to 0.
> > > > However, neither case accounts for interaction with PAM stack. In
> > > > PAM documentation there is no explanation what to expect from
> > > > session stack either, while side effects are kind of covered (in
> > > > pam_open_session(3)) by claiming that application should have
> > > > enough privileges to perform those operations that, for example,
> > > > create directories.
> > > > 
> > > > I suspect we should treat each PAM session as kind of a separate
> > > > instance launch in terms of our environment being clobbered. So
> > > > resetting umask to 0 is probably a valid thing.
> > > > 
> > > > 
> > > 
> > > What happens if you do not use systemd ?
> > 
> > It's not a systemd thing, it's a PAM thing :-(.
> 
> Always a bit dubious about anything to do with systemd and that manpage
> extract came from systemd, but I will take your word for it ;-)
No, there is no need to always be alerted. 

The concept of dropping umask to 0 in daemons on startup is a common
lore. You can find it in Dave Lennert's "How To Write a UNIX Daemon"
article[1] which originally appeared in the Volume 12, Number 4
(July/August 1987) issue[2] of the Usenix Association Newsletter,
;login: 

So by 1987 it was already a common practice.

[1] http://cjh.polyplex.org/software/daemon.pdf
[2] https://books.google.fi/books?id=UdM74Ipd3cAC&lpg=PA43&ots=3EB2T1alz5&dq=%22How%20To%20Write%20a%20UNIX%20Daemon%22&pg=PA43#v=onepage&q=%22How%20To%20Write%20a%20UNIX%20Daemon%22&f=false


-- 
/ Alexander Bokovoy