On 01/21/2015 04:20 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 2:47:57 PM
Subject: Re: [SSSD] Config file ownership and cwrap tests
On 01/21/2015 03:09 PM, Roland Mainz wrote:
Another option would be to modify fakeroot and intercept |open()| and
|creat()| ([1]) and replace it with calls to a virtual root via |openat()|
(AFAIK this should be easy to do since we just put the virtual root's fd in
front of the path and make the absolute paths relative to the virtual root
(open issue is how to communicate the fd to child processes of fakeroot);
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.
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 :) We don't want to require
running make check in a QEMU with NFS root :)
Otherwise I did some NFS root running during my embedded work and it worked
well.
Nick
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
