[SSSD] Config file ownership and cwrap tests

Roland Mainz rmainz at redhat.com
Wed Jan 21 11:54:42 UTC 2015



----- Original Message -----
> From: "Nikolai Kondrashov" <Nikolai.Kondrashov at redhat.com>
> To: "Development of the System Security Services Daemon" <sssd-devel at lists.fedorahosted.org>
> Sent: Friday, January 16, 2015 7:29:53 PM
> Subject: Re: [SSSD] Config file ownership and cwrap tests
> 
> On 01/16/2015 06:54 PM, Jakub Hrozek wrote:
> > On Fri, Jan 16, 2015 at 06:40:51PM +0200, Nikolai Kondrashov wrote:
> >> On 01/16/2015 02:48 PM, Lukas Slebodnik wrote:
> >>> On (16/01/15 14:22), Nikolai Kondrashov wrote:
> >>>> On 01/14/2015 08:09 PM, Lukas Slebodnik wrote:
> >>>>> Using fakeroot is much better solution then adding hack with env
> >>>>> variables.
> >>>>>
> >>>>> BTW fakeroot provides a fake root environment by means of LD_PRELOAD.
> >>>>> The only disadvantage of fakeroot is that is not available on all
> >>>>> platforms.
> >>>>> (but there is not problem to prepare COPR repo)
> >>>>>
> >>>>> So basically there is not a big difference between fakeroot and other
> >>>>> cwrap
> >>>>> packages.
> >>>>
> >>>> Just an update: it's not all rainbows in the fakeroot land either. It's
> >>>> not
> >>>> wrapping open()/create(). That means that all files sssd creates belong
> >>>> to
> >>>> root under fakeroot (even though it can chown them to anything), which
> >>>> is not
> >>>> compatible with --with-sssd-user.
> >>>>
> >>>> I'm also having some problem starting sssd as root under fakeroot.
> >>>> Something
> >>>> to do with D-BUS sockets probably.
> >>> We do not use dbus communication directly (execpt sssd_ifp.
> >>> We use unix sockets and libdbus is used just for marshaling.
> >>
> >> Ah, yes, I think I can see that now.
> >>
> >>>> Will keep digging.
> >>>
> >>> Feel free to send mails to sssd-devel with any problem.
> >>
> >> Thank you, Lukas.
> >>
> >> I think this has something to do with my problems:
> >>
> >>      stat("/root/.dbus-keyrings", 0x7fff248f2490) = -1 EACCES (Permission
> >>      denied)
> >
> > Which process does this? Can you post more context?
> >
> > The sbus communication is peer-to-peer..
> 
> sssd and sssd_be. I've got all the logs and straces and whatever. Basically,
> it seems D-Bus is trying to store its keyring in ~/.dbus-keyrings directory.
> With user being root it naturally tries to store it in /root/.dbus-keyrings.
> 
> Actually, as we have control of passswd database, we can put root's home
> anywhere. I'll try that.

Erm... isn't that risky ? Other applications running as user "root" in parallel to what you're doing might trip over such a change...
... is there no way to override the keyring location (quick look at |dbus_keyring_new_homedir()| doesn't show any way... but maybe one of the DBus experts might know a way. If this fails there is always /proc/$pid/root/ which can AFAIK be overridden on a per-process basis (details on demand, I have to dig out how this works...)) ?

----

Bye,
Roland

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



More information about the sssd-devel mailing list