Fix for Samba server masking world writeable perm off

[Alexander Bokovoy]

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.


-- 
/ Alexander Bokovoy