On 01/21/2015 07:03 PM, Roland Mainz wrote:
----- Original Message -----
From: "Nikolai Kondrashov" <nikolai.kondras...@redhat.com>
To: "Development of the System Security Services Daemon"
<sssd-devel@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
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
