[SSSD] Config file ownership and cwrap tests

Lukas Slebodnik lslebodn at redhat.com
Wed Jan 14 17:55:22 UTC 2015


On (14/01/15 17:10), Nikolai Kondrashov wrote:
>On 01/14/2015 04:56 PM, Nikolai Kondrashov wrote:
>>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.
>
>I'd like to note that this is only one of the first obstacles to implementing
>robust integration testing in "make check". I wouldn't like to go nuclear
If running integration test from "make check" causes many troubles than this
decision should be reconsidered.

Personally I will not have a problem if there is separate script which would
execute integration test suite.

LS



More information about the sssd-devel mailing list