Fix for Samba server masking world writeable perm off

Alexander Bokovoy ab at samba.org
Tue Feb 26 18:18:43 UTC 2019


On ti, 26 helmi 2019, Rowland Penny wrote:
> On Tue, 26 Feb 2019 19:24:29 +0200
> Alexander Bokovoy <ab at samba.org> wrote:
> 
> > 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. 
> 
> I said 'dubious', not alert, I do not go out of my way looking for
> things about systemd, but when something pops up in front of me and I
> don't fully understand it, I ask. I got the answer, time to move on ;-)
:)

> 
> > 
> > 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.
> 
> I have never come across it before, so I didn't know about it, nobody
> can know everything and I fall far far from everything ;-)
This is just fine. I can pretend I knew it but in reality I just love
archeology so much that I was able to dig it up on request. :)

-- 
/ Alexander Bokovoy



More information about the samba-technical mailing list