Fix for Samba server masking world writeable perm off

Rowland Penny rpenny at
Tue Feb 26 16:44:21 UTC 2019

On Tue, 26 Feb 2019 18:31:55 +0200
Alexander Bokovoy via samba-technical <samba-technical at>

> 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 ?


More information about the samba-technical mailing list