[SSSD] [PATCH] Monitor and sbus changes for running SSSD as a non-privileged user

Michal Židek mzidek at redhat.com
Thu Oct 16 18:39:16 UTC 2014


On 10/16/2014 03:05 PM, Simo Sorce wrote:
> On Thu, 16 Oct 2014 10:23:35 +0200
> Jakub Hrozek <jhrozek at redhat.com> wrote:
>
>> On Wed, Oct 15, 2014 at 06:17:55PM -0400, Simo Sorce wrote:
>>> On Wed, 15 Oct 2014 22:24:04 +0200
>>> Jakub Hrozek <jhrozek at redhat.com> wrote:
>>>
>>>>  From c0385561ee5e9d050d2222aa43ebf46514f37dad Mon Sep 17 00:00:00
>>>> 2001 From: Michal Zidek <mzidek at redhat.com>
>>>> Date: Thu, 9 Oct 2014 17:15:56 +0200
>>>> Subject: [PATCH 5/7] MONITOR: Allow confdb to be accessed by
>>>> nonroot user
>>>>
>>>> ---
>>>>   src/monitor/monitor.c | 11 ++++++++++-
>>>>   1 file changed, 10 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/src/monitor/monitor.c b/src/monitor/monitor.c
>>>> index
>>>> 44614be173325aa5b6f7ed03f00b6d4489ddf522..bd2c373008ef75ab46cf7dccdefd12468894f1ba
>>>> 100644 --- a/src/monitor/monitor.c +++ b/src/monitor/monitor.c
>>>> @@ -1718,7 +1718,6 @@ static errno_t load_configuration(TALLOC_CTX
>>>> *mem_ctx, DEBUG(SSSDBG_FATAL_FAILURE, "Fatal error initializing
>>>> confdb\n"); goto done;
>>>>       }
>>>> -    talloc_zfree(cdb_file);
>>>>
>>>>       ret = confdb_init_db(config_file, ctx->cdb);
>>>>       if (ret != EOK) {
>>>> @@ -1734,6 +1733,16 @@ static errno_t
>>>> load_configuration(TALLOC_CTX *mem_ctx, goto done;
>>>>       }
>>>>
>>>> +    /* Allow configuration database to be accessible
>>>> +     * when SSSD runs as nonroot */
>>>> +    ret = chown(cdb_file, ctx->uid, ctx->gid);
>>>> +    if (ret != EOK) {
>>>> +        DEBUG(SSSDBG_FATAL_FAILURE,
>>>> +              "chown failed for [%s]: [%d][%s].\n",
>>>> +              cdb_file, ret, sss_strerror(ret));
>>>> +        goto done;
>>>> +    }
>>>> +
>>>>       *monitor = ctx;
>>>>
>>>>       ret = EOK;
>>>
>>>
>>> I wonder if we shouldn't be more cautious here.
>>> Do we need to give the sssd user write access ?
>>> I think probably not, sounds like a great way to prevent
>>> "accidental" changes would be to chown to (0, gid) and chmod so
>>> that the group can only read, while root can read/write.
>>>
>>> This way non-root process will be allowed to read but not change the
>>> database.
>>
>> But the sssd_be processes should also run as non-root if possible and
>> it needs to write to the db.
>
> To the configuration db ?
> Why ?
>
>> In general, the current plan is that sssd_be would start as root, do
>> whatever privileged initialization it needs and drop to sssd user,
>> too. Then, any operations that need to be done with different
>> privileges will be done either in setuid helper (ldap_child,
>> krb5_child with validation, setting the SELinux context) or in a
>> helper running as the user on whose behalf we are authenticating
>> (krb5_child when keytab validation is not needed).
>>
>> This way, only the monitor and the proxy_child will run privileged..
>
> Yes, and the children usually do not read the confdb at all as they get
> their parameters from the invoking process.
>
> In what case does anything need to write to the confdb after the file
> has been generated by the monitor ?
>
> Simo.
>


Hi,

I just tried to set new rights for confdb so that root can read/write
and responders (user sssd) can read. The solution was this:
file owned by user: root, group: sssd. File permissions 0640.

But than ldb failed to connect. I guess the problem was that I
did not pass LDB_FLAGS_READONLY to ldb_connect() call. So I
added new parameter to server_setup() and confdb_init(), so that
in responders I could init confdb with this parameter (not in monitor).

But ldb_connect() still fails. I am not sure what the problem is.
In logs I can see this:

(Thu Oct 16 20:23:38:525086 2014) [sssd[pam]] [ldb] (0x0010): ldb error 
(ldb_wait: Operations error (1)) occurred searching for modules, bailing out
(Thu Oct 16 20:23:38:525163 2014) [sssd[pam]] [ldb] (0x0010): Unable to 
load modules for /var/lib/sss/db/config.ldb: ldb_wait: Operations error (1)
(Thu Oct 16 20:23:38:525191 2014) [sssd[pam]] [confdb_init] (0x0010): 
Unable to open config database [/var/lib/sss/db/config.ldb]
(Thu Oct 16 20:23:38:525252 2014) [sssd[pam]] [server_setup] (0x0010): 
The confdb initialization failed

I am not really sure what the problem is right now. Would it
be OK, to have the confdb readable and writeable by responders
for now, and file a ticket to fix this later?

Michal



More information about the sssd-devel mailing list