Fix for Samba server masking world writeable perm off

[Jeremy Allison]

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 :-(.