[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