[SSSD] Config file ownership and cwrap tests

Roland Mainz rmainz at redhat.com
Wed Jan 21 17:03:31 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: Wednesday, January 21, 2015 3:49:39 PM
> Subject: Re: [SSSD] Config file ownership and cwrap tests
[snip]
> >> Fakeroot doesn't intercept open()/creat() because it was seen creating
> >> problems with libc upgrades
> >
> > Why ? AFAIK (if I get this right) the problem is "loops inside the
> > emulation
> > code" and the issue that glibc doesn't follow the UNIX convention of
> > separating internal (libc-to-libc) vs. external libc calls... but that can
> > AFAIK be solved via a per-thread flag (|pthread_key_create()| can be used
> > to
> > keep the code portable; two issues need to be worked out: 1. syscalls
> > inside
> > signal handlers and 2. thread cancellation points) to indicate that we're
> > inside the wrapper mechanism.
> 
> That could, perhaps, be a solution to the particular hairness of wrapping
> libc
> which calls itself. However, that would still be a requirement of a special
> package (in this case modified fakeroot) for our "make check" run, which we
> would like to avoid.

... or add an option to "fakeroot" via patch (fix wrapper call loop detection, add optional |open()|/|openat()|/etc. wrappers), submit it to upstream and make that new option the minimum we need for testing (OKOK... it's at least a manweek of work and it'll take some months until the changes will bleed through into our stable repositories... ;-(( ) ... 

> I think we should be able to manage with stock fakeroot for sssd configured
> for running as root and no fakeroot otherwise.
> 
> >> and we would be in a special risk here testing on
> >> Debian Testing and Fedora Rawhide.
> >
> > What is the problem with testing on Debian ?
> 
> No problem except the higher chance of a libc upgrade, similarly to Fedora
> Rawhide.

;-((

> >> At least some of the virtual root stuff is
> >> done by fakechroot, but that is still not available everywhere and so is
> >> close
> >> to a custom package solution. Then, again, we don't want to create our own
> >> chroot environment (fake or otherwise), if we can.
> >
> > OK... next crazy option would be testing via NFS root (see
> > http://fedoraproject.org/wiki/Dracut) and qemu... I did lots of work
> > related
> > to this for testing Kerberos5 in a isolated multi-machine environment which
> > can be fully controlled by scripts (without having to own multiple
> > machines)
> > and it seems to work (drawback is that you need to invest lots of time (and
> > cursing) to have all the pieces together, but once you're past that point
> > it
> > works quite good).
> 
> Woah, woah, that's definitely a crazy option :)

You wanted testing as (pseudo-)"root" with standard packages and being compatible to all applications (real driving point would be to do tests with multiple machines) ...

> We don't want to require
> running make check in a QEMU with NFS root :)

OK...
... then what about a minimum-size/effort approach: LD_PRELOAD wrapper which intercepts |open()|&co. to just redirect that single keyring access ?

----

Bye,
Roland

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



More information about the sssd-devel mailing list