Fix for Samba server masking world writeable perm off

[Rowland Penny]

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 ;-)

Rowland