[SSSD] Config file ownership and cwrap tests

Nikolai Kondrashov Nikolai.Kondrashov at redhat.com
Thu Jan 15 10:39:35 UTC 2015


On 01/14/2015 05:00 PM, 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.Kondrashov at 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.

Simo, do you have anything against this? I.e. allowing sssd.conf to belong to
sssd.sssd as well as to root.root?

Thank you.

Nick



More information about the sssd-devel mailing list