On 01/14/2015 02:17 PM, Nikolai Kondrashov wrote:
On 01/14/2015 08:58 PM, Dmitri Pal wrote:
On 01/14/2015 10:00 AM, Nikolai Kondrashov wrote:
On 01/14/2015 04:48 PM, Simo Sorce wrote:
On Wed, 14 Jan 2015 16:08:33 +0200
Nikolai Kondrashov <nikolai.kondras...@redhat.com> wrote:
On 01/13/2015 02:31 PM, Nikolai Kondrashov wrote:
Hi everyone,
I have a bit of a chicken/egg problem with implementing cwrap tests.
Sssd currently requires the config file to belong to root. However,
that is not possible to arrange when running under a regular user,
in cwrap tests. Even though uid_wrapper fakes running under root,
the created files still belong to the real user.
I see two ways out of this: either run under fakeroot, or allow the
config file to (also?) belong to the user sssd is configured to run
under (target user).
While fakeroot will likely work, to me it seems like sweeping the
problem under the rug. The second option seems a bit more natural,
especially considering that the CDB file is explicitly chown'ed to
the target user, anyway.
Now, since the target user can be configured both at the build time
*and* in the configuration file itself, we'll need to verify file
ownership *after* reading it. Or, can we maybe move user
specification to command-line option?
What do you think?
Simo, do you have any thoughts on this?
It is blocking my cwrap LDAP integration test implementation.
Uhmmm though problem, I think, for this very special case, we may want
an env var that allows the code to relax permission/ownership checking
on the config file.
Would there be a problem if we allow sssd.conf to belong to the user
we're
running under, as well? The daemons run under that user and CDB file is
chowned to it anyway.
I do not generally like magic env variables, and we should have an
option to compile this support out perhaps, but I see no other sane
way
short of intercepting stat() and faking permission/ownership only for
this case.
I wouldn't like another magic variable either. Could we perhaps get
away with
fakeroot here? It doesn't seem to me that LDAP integration testing
would be
very much affected by the potential bugs that it would hide.
Thank you.
Nick
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
How about the following approach:
Add a switch to SSSD called --allow-user=uid
If the switch is provided allow sssd.conf to be readable to root or
this user, i.e. check for both. If not provided then check for just
root as we always do.
Run tests as this user and pass this switch in case of make check.
Would that work?
Thank you. That would, of course work, and be acceptable WRT the
integration
tests, but to me this seems polluting sssd option namespace for a very
superficial feature.
Nick
But is probably the simplest couple dozen line patch which can be done
in less time that we spend in this thread. :-)
But allowing sssd.sssd. user to own the file is fine with me, however we
would have to change the error message, man pages and docs. Sounds like
more effort to me...
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
