[SSSD] Config file ownership and cwrap tests

Nikolai Kondrashov Nikolai.Kondrashov at redhat.com
Wed Jan 14 14:56:32 UTC 2015


On 01/14/2015 04:13 PM, Lukas Slebodnik wrote:
> On (14/01/15 16:08), Nikolai Kondrashov 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.
>>
> I was thiking you want to discuss about more complex solution
> (in cwrap or in sssd).
>
> and we would use a temporary workaround proposed in
> https://lists.fedorahosted.org/pipermail/sssd-devel/2015-January/022232.html
> I would not say it is a blocker.

Sorry, I was probably confusing here. I'll try to list the solutions I propose
in order of (my own) precedence:

1. Change sssd to allow sssd.conf to belong to the target user, in addition to
    the already accepted root. I think this is safe, because it is not much
    different from having the server processes run as that user. Also, CDB file
    is chowned to that user anyway. I see at least two ways to implement it
    ATM:

    1.1. Have configuration file permissions verified against both root and the
         target user *after* reading it. Essentially, add check for target user
         owner to sss_ini_config_access_check and move its invocation out of
         confdb_init_db, and into load_configuration, after get_monitor_config,
         as the latter retrieves the target user.

    1.2. Move target user specification out of sssd.conf and into a
         command-line option, leaving permission checking in its place, and
         only adding the option for sssd.conf to belong to target user.
         That might be too late, though.

    The benefits: precise, low maintenance and side-effects.

2. Use fakeroot. The benefits: simple and tested approach, also allows working
    around further file permission restrictions. The drawback: can hide other
    defects, but those would likely be irrelevant to LDAP integration testing.

3. Use a dedicated LD_PRELOAD wrapper replacing ini_config_access_check, as
    suggested by Lukas. This has the benefit of being more precise and thus
    potentially less prone to hide other defects, although those would be
    essentially irrelevant to LDAP integration testing. The drawback is more
    complexity and maintenance.

I still don't quite understand what's preventing us from implementing #1,
sorry.

Nick



More information about the sssd-devel mailing list