On 10/16/2014 03:05 PM, Simo Sorce wrote:
On Thu, 16 Oct 2014 10:23:35 +0200
Jakub Hrozek <jhrozek(a)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(a)redhat.com> wrote:
>>
>>> From c0385561ee5e9d050d2222aa43ebf46514f37dad Mon Sep 17 00:00:00
>>> 2001 From: Michal Zidek <mzidek(a)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