[SSSD] Config file ownership and cwrap tests

Nikolai Kondrashov Nikolai.Kondrashov at redhat.com
Thu Jan 22 12:19:40 UTC 2015


On 01/21/2015 07:03 PM, Roland Mainz wrote:
> ----- 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... ;-(( ) ...

Yeah...

>>>> 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) ...

Well, first of all we don't really want "all" aplications at the moment, just
sssd and Python. The multiple machine integration testing in CI is in the
plan, but it's a whole other can of worms and I think we can still do a lot
with just cwrap on a single host.

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

That could work, but I already worked that around by moving the root's
home directory :)

Thanks for brainstorming, Roland!

Nick



More information about the sssd-devel mailing list