On 01/21/2015 03:09 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 1:19:57 PM
Subject: Re: [SSSD] Config file ownership and cwrap tests
On 01/21/2015 02:05 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: Friday, January 16, 2015 1:22:29 PM
Subject: Re: [SSSD] Config file ownership and cwrap tests
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.
Does Fedora have union mounts (originally from Plan 9, AFAIK Linux calls
this "unionfs" or "overlayfs") ? If "yes" then some stunts with unionfs and
|chroot()| should be possible for testing. Let me know if I should dig-out
the details...
I guess it does, but that would require a real root, which is against our
requirements of running from within a "make check" as a regular user.
setid (setuid/setgid) wrapper which does the { union mount, does |chroot()|,
executes command in that environment } is no option ?
It could be a last resort option, but I think we're better off not requiring
any special packages just for "make check" and we can do away with modifying
sssd itself to be more flexible. I don't think there are any real technical
obstacles there.
As such it seems it works with fakeroot, uid_wrapper and nss_wrapper, which
should be good for the start.
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 and we would be in a special risk here testing on
Debian Testing and 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.
but this is still not bullet-proof, e.g. anything which does a $ env - ... #
will leave your fakeroot-jail and any /proc/-based path-relative filesystem
accesses will fail, too) ...
Apart from this being a too burdensome solution, I think it would have been
sufficient.
[1]=(... and |openat()| and most of the other filesystem syscalls (AFAIK the
list in
http://svn.nrubsig.org/svn/people/gisburn/code/openat_emu/ast_map_fsat.h
could be used as template))
Thanks for the suggestions, Roland!
Nick
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
