[SSSD] Pass fd's around via /proc/$pid/fd/ ... / was: Re: sssd.conf ownership

Roland Mainz rmainz at redhat.com
Thu Nov 27 14:11:59 UTC 2014



----- Original Message -----
> From: "Jakub Hrozek" <jhrozek at redhat.com>
> To: sssd-devel at lists.fedorahosted.org
> Sent: Saturday, November 22, 2014 2:24:17 PM
> Subject: Re: [SSSD] sssd.conf ownership
> 
> On Fri, Nov 21, 2014 at 04:26:58PM -0500, Stephen Gallagher wrote:
> > 
> > 
> > 
> > On Fri, 2014-11-21 at 20:03 +0100, Jakub Hrozek wrote:
> > > Hi,
> > > 
> > > I was going through our design page that describes the rootless sssd and
> > > I'd like to discuss the default ownership of sssd.conf a bit more.
> > > 
> > > In the design document we proposed to change the default ownership to
> > > sssd.sssd. This wouldn't widen sssd.conf access as only root and the sssd
> > > user could read the config. One reason for the change was the dbus helper
> > > to change the config, which would otherwise run privileged.
> > > 
> > > But I wonder whether it's really the best approach. If we changed the
> > > ownership to sssd.sssd, then we'd have to be careful about chowning the
> > > file each time on startup because tools like authconfig or even
> > > customer's
> > > puppet modules or whatnot will keep writing out the file as root.root. We
> > > can't reasonably change all the external tools and chowning on each
> > > startup seems a bit fragile (as opposed to chowning the databases which
> > > is a one-time operation).
> > > 
> > > Also, if we kept the the config file owned by root, then making the
> > > confdb read-only for worker processes would mean the worker processes
> > > have no means of altering the config file even if they were taken over.
> > > 
> > > The downside of keeping the sssd.conf as root is that the augeas calls
> > > would have to be moved to a setuid process -- and a new setuid process is
> > > always a bit of a burden.
> > > 
> > > To sum up:
> > >     * sssd.sssd
> > >         (+) don't need any privileged code to access sssd.conf
> > >         (-) need to chown the file on each startup
> > >     * root.root
> > >         (+) config file is only writable by privileged processes
> > >         (+) we're able to make the confdb read-only
> > >         (-) need privileged code to perform sssd.conf changes
> > > 
> > > I do realize that the complexity of creating the setuid helpers is much
> > > larger than the complexity of writing a function to chown a file, but
> > > for some reason the chowning feels a bit fragile to me and my gut
> > > feeling is that the config file would better be only accessible by
> > > root...
> > > 
> > > What do the other developers think?
> > 
> > Why exactly would it need to be chown()ed? I'm unclear on that point.
> > Presumably, SSSD is still being launched as root and then dropping
> > privileges (otherwise it wouldn't be able to perform the chown). So to
> > me it seems like it makes sense to just open the file read-only prior to
> > dropping privileges, then pass the filehandle along.
> 
> Passing a fd would be best, but infortunately the augeas API we use to
> change the configuration only works with path names ...

Erm... you can use /proc/$pid/fd/ ...

... example:
-- snip --
$ ksh -c 'printf "chickenmonster666\n" >xxx ; redirect {fd}<"xxx" ; fdpath="/proc/$$/fd/$fd" ; env - fdpath="$fdpath" /usr/bin/bash -c "cat $fdpath" ; true' 
chickenmonster666
-- snip --
(the last "true" is needed to prevent ksh93 from doing a tail-call optimisation and |exec()| the last command in the command line in place of the ksh93 process... this would not work in this case because the /proc/$pid/fd/ files only live as long as the parent process lives (but you can |openat()| the fds via /proc)).

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) rmainz at redhat.com
  \__\/\/__/  IPA/Kerberos5 team
  /O /==\ O\  
 (;O/ \/ \O;)
 



More information about the sssd-devel mailing list