Fields changed

description: Recently we started effort to allow SSSD responders and backend to run as non-root.
The confdb database (config.ldb) is initialized in monitor (which runs as root) and
responders (that run as sssd user) only read it. So it makes sense to give only read
permissions to the sssd user (while root has read/write).

To do this let the file be owned by:[[BR]]
user:root[[BR]]
group:sssd[[BR]]

And set permissions to 0640.[[BR]]

NOTE: I already tried to do this and had some problems initializing the config.ldb as read-only in the responders. Here is the original mail:
{{{
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
}}}

=> Recently we started effort to allow SSSD responders and backend to run as non-root.
The confdb database (config.ldb) is initialized in monitor (which runs as root) and
responders (that run as sssd user) only read it. So it makes sense to give only read
permissions to the sssd user (while root has read/write).

To do this let the file be owned by:[[BR]]

user:root[[BR]]

group:sssd[[BR]]

And set permissions to 0640.[[BR]]

NOTE: I already tried to do this and had some problems initializing the config.ldb as read-only in the responders. Here is the original mail:
{{{
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
}}}

Fields changed

description: Recently we started effort to allow SSSD responders and backend to run as non-root.
The confdb database (config.ldb) is initialized in monitor (which runs as root) and
responders (that run as sssd user) only read it. So it makes sense to give only read
permissions to the sssd user (while root has read/write).

To do this let the file be owned by:[[BR]]

user:root[[BR]]

group:sssd[[BR]]

And set permissions to 0640.[[BR]]

NOTE: I already tried to do this and had some problems initializing the config.ldb as read-only in the responders. Here is the original mail:
{{{
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
}}}

=> Recently we started effort to allow SSSD responders and backend to run as non-root.
The confdb database (config.ldb) is initialized in monitor (which runs as root) and
responders (that run as sssd user) only read it. So it makes sense to give only read
permissions to the sssd user (while root has read/write).

To do this let the file be owned by:[[BR]]

user:root [[BR]]

group:sssd [[BR]]

And set permissions to 0640.[[BR]]

NOTE: I already tried to do this and had some problems initializing the config.ldb as read-only in the responders. Here is the original mail:
{{{
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
}}}

This is an ongoing hardening of confdb. Nice to have.

milestone: NEEDS_TRIAGE => SSSD 1.14 beta

Fields changed

rhbz: => 0

I still think this would be nice to have, but 1.14 is already getting very big..

milestone: SSSD 1.14 beta => SSSD 1.15 beta
sensitive: => 0

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/3511

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.