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?
Thank you.
Nick
On (13/01/15 14:31), 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?
We will use lot of "hacks" with cwrap tests. So we can use yet another. We can mock(LD_PRELOAD own version) ini_config_access_check that it will return EOK for sssd.conf although owner is not root.
LS
On 01/13/2015 03:09 PM, Lukas Slebodnik wrote:
On (13/01/15 14:31), Nikolai Kondrashov wrote:
What do you think?
We will use lot of "hacks" with cwrap tests. So we can use yet another. We can mock(LD_PRELOAD own version) ini_config_access_check that it will return EOK for sssd.conf although owner is not root.
Hm, that will work, but it seems to me a bit of an overkill. Can we get away with just a code change?
Nick
On (13/01/15 15:23), Nikolai Kondrashov wrote:
On 01/13/2015 03:09 PM, Lukas Slebodnik wrote:
On (13/01/15 14:31), Nikolai Kondrashov wrote:
What do you think?
We will use lot of "hacks" with cwrap tests. So we can use yet another. We can mock(LD_PRELOAD own version) ini_config_access_check that it will return EOK for sssd.conf although owner is not root.
Hm, that will work, but it seems to me a bit of an overkill. Can we get away with just a code change?
There was a long discussion about ownership of the sssd configuration file few months ago. "[SSSD] sssd.conf ownership" https://lists.fedorahosted.org/pipermail/sssd-devel/2014-November/021628.htm... You can try to continue discussion there.
The main reason why root need to be owner is that sssd.conf can contain password (ldap_default_authtok).
We should not try to do any changes to this critical part of sssd. This is a reason why we decided to use *_wraper
Jakub Is it a candidate for another wrppper?
LS
On 01/13/2015 05:36 PM, Lukas Slebodnik wrote:
On (13/01/15 15:23), Nikolai Kondrashov wrote:
On 01/13/2015 03:09 PM, Lukas Slebodnik wrote:
On (13/01/15 14:31), Nikolai Kondrashov wrote:
What do you think?
We will use lot of "hacks" with cwrap tests. So we can use yet another. We can mock(LD_PRELOAD own version) ini_config_access_check that it will return EOK for sssd.conf although owner is not root.
Hm, that will work, but it seems to me a bit of an overkill. Can we get away with just a code change?
There was a long discussion about ownership of the sssd configuration file few months ago. "[SSSD] sssd.conf ownership" https://lists.fedorahosted.org/pipermail/sssd-devel/2014-November/021628.htm... You can try to continue discussion there.
The main reason why root need to be owner is that sssd.conf can contain password (ldap_default_authtok).
We should not try to do any changes to this critical part of sssd. This is a reason why we decided to use *_wraper
Ah, thank you, Lukas. I thought I found a discussion of this, but it was the wrong one. I'll take a look.
Nick
On 01/13/2015 05:36 PM, Lukas Slebodnik wrote:
On (13/01/15 15:23), Nikolai Kondrashov wrote:
On 01/13/2015 03:09 PM, Lukas Slebodnik wrote:
On (13/01/15 14:31), Nikolai Kondrashov wrote:
What do you think?
We will use lot of "hacks" with cwrap tests. So we can use yet another. We can mock(LD_PRELOAD own version) ini_config_access_check that it will return EOK for sssd.conf although owner is not root.
Hm, that will work, but it seems to me a bit of an overkill. Can we get away with just a code change?
There was a long discussion about ownership of the sssd configuration file few months ago. "[SSSD] sssd.conf ownership" https://lists.fedorahosted.org/pipermail/sssd-devel/2014-November/021628.htm... You can try to continue discussion there.
I read it, but it seems this issue, although related, is independent of that one. So, I'll try here.
The main reason why root need to be owner is that sssd.conf can contain password (ldap_default_authtok).
If sssd runs as a non-root user, then there's not much added security in keeping sssd.conf belonging to root, instead of that user. That user can always attach a debugger to sssd, or dump its /proc/PID/mem and extract all the passwords.
I'm not exactly proposing we change the canonical (default) sssd.conf ownership, rather allow sssd.conf belong to the running user as well as root.
What negative effects would that have?
We should not try to do any changes to this critical part of sssd. This is a reason why we decided to use *_wraper
Can we just use fakeroot? It's a well-tested wrapper, although its scope might be a bit too wide for us.
Nick
P.S. Just an opinion: I don't feel it's a good idea for sssd to enforce ownership/permissions of its *input* files at all. The input file permissions don't affect actual function, as long as it's readable, and this artificial restriction hurts modularity and complicates both sssd and interacting code unnecessarily. I see what this tries to accomplish, I just don't think it's any of sssd's business. Nevertheless, I don't propose we change this.
On (14/01/15 14:36), Nikolai Kondrashov wrote:
On 01/13/2015 05:36 PM, Lukas Slebodnik wrote:
On (13/01/15 15:23), Nikolai Kondrashov wrote:
On 01/13/2015 03:09 PM, Lukas Slebodnik wrote:
On (13/01/15 14:31), Nikolai Kondrashov wrote:
What do you think?
We will use lot of "hacks" with cwrap tests. So we can use yet another. We can mock(LD_PRELOAD own version) ini_config_access_check that it will return EOK for sssd.conf although owner is not root.
Hm, that will work, but it seems to me a bit of an overkill. Can we get away with just a code change?
There was a long discussion about ownership of the sssd configuration file few months ago. "[SSSD] sssd.conf ownership" https://lists.fedorahosted.org/pipermail/sssd-devel/2014-November/021628.htm... You can try to continue discussion there.
I read it, but it seems this issue, although related, is independent of that one. So, I'll try here.
The main reason why root need to be owner is that sssd.conf can contain password (ldap_default_authtok).
If sssd runs as a non-root user, then there's not much added security in keeping sssd.conf belonging to root, instead of that user. That user can always attach a debugger to sssd, or dump its /proc/PID/mem and extract all the passwords.
A) not all processes run as non-root. The main process (sssd) which load configuration file still run as root.
B) Other processes will run asa system user ("sssd") which does not have a shell orpassword. sssd:x:983:969:User for sssd:/:/sbin/nologin
I'm not aware of way how other users could attach debugger to the processes of another user (or read /proc/PID/mem). It would be a security hole.
So it is not a valid argument.
LS
On 01/14/2015 02:47 PM, Lukas Slebodnik wrote:
On (14/01/15 14:36), Nikolai Kondrashov wrote:
On 01/13/2015 05:36 PM, Lukas Slebodnik wrote:
On (13/01/15 15:23), Nikolai Kondrashov wrote:
On 01/13/2015 03:09 PM, Lukas Slebodnik wrote:
On (13/01/15 14:31), Nikolai Kondrashov wrote:
What do you think?
We will use lot of "hacks" with cwrap tests. So we can use yet another. We can mock(LD_PRELOAD own version) ini_config_access_check that it will return EOK for sssd.conf although owner is not root.
Hm, that will work, but it seems to me a bit of an overkill. Can we get away with just a code change?
There was a long discussion about ownership of the sssd configuration file few months ago. "[SSSD] sssd.conf ownership" https://lists.fedorahosted.org/pipermail/sssd-devel/2014-November/021628.htm... You can try to continue discussion there.
I read it, but it seems this issue, although related, is independent of that one. So, I'll try here.
The main reason why root need to be owner is that sssd.conf can contain password (ldap_default_authtok).
If sssd runs as a non-root user, then there's not much added security in keeping sssd.conf belonging to root, instead of that user. That user can always attach a debugger to sssd, or dump its /proc/PID/mem and extract all the passwords.
A) not all processes run as non-root. The main process (sssd) which load configuration file still run as root.
Alright.
B) Other processes will run asa system user ("sssd") which does not have a shell orpassword. sssd:x:983:969:User for sssd:/:/sbin/nologin
I'm not aware of way how other users could attach debugger to the processes of another user (or read /proc/PID/mem). It would be a security hole.
True, I missed that.
So it is not a valid argument.
Still, for that matter, they won't be able to read the file either.
Nick
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.
Nick
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.
LS
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.
Nick
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:
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.
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.
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 right from the start and implement something complicated or add configuration options, because there will be more similar problems and I'd like to minimize the number of hacks needed to make the whole solution as mainstream as possible.
I'm witholding discussion of other issues for now to keep us more focused.
Nick
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:
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.
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.
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
On 01/14/2015 07:55 PM, Lukas Slebodnik wrote:
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:
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.
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.
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.
I agree, there would be not much difference between "make check" and a separate script and I see some benefits for the latter. However, main problems I face right now are running as non-root and without installing.
Still, I managed to get LDAP users listed via sssd under "make check". Although the setup and hacks weren't pretty.
Nick
On Wed, 14 Jan 2015 16:08:33 +0200 Nikolai Kondrashov Nikolai.Kondrashov@redhat.com 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.
Uhmmm though problem, I think, for this very special case, we may want an env var that allows the code to relax permission/ownership checking on the config file.
I do not generally like magic env variables, and we should have an option to compile this support out perhaps, but I see no other sane way short of intercepting stat() and faking permission/ownership only for this case.
Simo.
On Wed, Jan 14, 2015 at 09:48:06AM -0500, Simo Sorce wrote:
On Wed, 14 Jan 2015 16:08:33 +0200 Nikolai Kondrashov Nikolai.Kondrashov@redhat.com 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.
Uhmmm though problem, I think, for this very special case, we may want an env var that allows the code to relax permission/ownership checking on the config file.
I do not generally like magic env variables, and we should have an option to compile this support out perhaps, but I see no other sane way short of intercepting stat() and faking permission/ownership only for this case.
+1 we already have some other cases where we have #ifdef UNIT_TESTS, so an environment variable with sufficiently weird name to avoid accidental conflicts sounds like a good idea
On (14/01/15 15:54), Jakub Hrozek wrote:
On Wed, Jan 14, 2015 at 09:48:06AM -0500, Simo Sorce wrote:
On Wed, 14 Jan 2015 16:08:33 +0200 Nikolai Kondrashov Nikolai.Kondrashov@redhat.com 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.
Uhmmm though problem, I think, for this very special case, we may want an env var that allows the code to relax permission/ownership checking on the config file.
I do not generally like magic env variables, and we should have an option to compile this support out perhaps, but I see no other sane way short of intercepting stat() and faking permission/ownership only for this case.
+1 we already have some other cases where we have #ifdef UNIT_TESTS
And I hate them because in most cases it means that code stink. (But it would take a lot of effort to fix it)
an environment variable with sufficiently weird name to avoid accidental conflicts sounds like a good idea
We have a ticket for removing usage of env variable from *_child. I do not see any benefit from adding env just for tests.
Using fakeroot is much better solution then adding hack with env variables.
BTW fakeroot provides a fake root environment by means of LD_PRELOAD. The only disadvantage of fakeroot is that is not available on all platforms. (but there is not problem to prepare COPR repo)
So basically there is not a big difference between fakeroot and other cwrap packages.
LS
On Wed, Jan 14, 2015 at 07:09:07PM +0100, Lukas Slebodnik wrote:
On (14/01/15 15:54), Jakub Hrozek wrote:
On Wed, Jan 14, 2015 at 09:48:06AM -0500, Simo Sorce wrote:
On Wed, 14 Jan 2015 16:08:33 +0200 Nikolai Kondrashov Nikolai.Kondrashov@redhat.com 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.
Uhmmm though problem, I think, for this very special case, we may want an env var that allows the code to relax permission/ownership checking on the config file.
I do not generally like magic env variables, and we should have an option to compile this support out perhaps, but I see no other sane way short of intercepting stat() and faking permission/ownership only for this case.
+1 we already have some other cases where we have #ifdef UNIT_TESTS
And I hate them because in most cases it means that code stink. (But it would take a lot of effort to fix it)
an environment variable with sufficiently weird name to avoid accidental conflicts sounds like a good idea
We have a ticket for removing usage of env variable from *_child. I do not see any benefit from adding env just for tests.
Using fakeroot is much better solution then adding hack with env variables.
BTW fakeroot provides a fake root environment by means of LD_PRELOAD. The only disadvantage of fakeroot is that is not available on all platforms. (but there is not problem to prepare COPR repo)
So basically there is not a big difference between fakeroot and other cwrap packages.
I admit I know very little about fakeroot, but is it going to be useful except this one problem?
If yes, then fine, but if it's just about ownership of this single file, then an environment variable or an ifdef is just easier. I think it goes without saying that the ifdef shouldn't be in the general code, but enclosed in a function, see 3fd66df4813d1410c1a6187c80e3a23395b14aed
On 01/14/2015 10:06 PM, Jakub Hrozek wrote:
On Wed, Jan 14, 2015 at 07:09:07PM +0100, Lukas Slebodnik wrote:
On (14/01/15 15:54), Jakub Hrozek wrote:
On Wed, Jan 14, 2015 at 09:48:06AM -0500, Simo Sorce wrote:
On Wed, 14 Jan 2015 16:08:33 +0200 Nikolai Kondrashov Nikolai.Kondrashov@redhat.com 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.
Uhmmm though problem, I think, for this very special case, we may want an env var that allows the code to relax permission/ownership checking on the config file.
I do not generally like magic env variables, and we should have an option to compile this support out perhaps, but I see no other sane way short of intercepting stat() and faking permission/ownership only for this case.
+1 we already have some other cases where we have #ifdef UNIT_TESTS
And I hate them because in most cases it means that code stink. (But it would take a lot of effort to fix it)
an environment variable with sufficiently weird name to avoid accidental conflicts sounds like a good idea
We have a ticket for removing usage of env variable from *_child. I do not see any benefit from adding env just for tests.
Using fakeroot is much better solution then adding hack with env variables.
BTW fakeroot provides a fake root environment by means of LD_PRELOAD. The only disadvantage of fakeroot is that is not available on all platforms. (but there is not problem to prepare COPR repo)
So basically there is not a big difference between fakeroot and other cwrap packages.
I admit I know very little about fakeroot, but is it going to be useful except this one problem?
If yes, then fine, but if it's just about ownership of this single file, then an environment variable or an ifdef is just easier. I think it goes without saying that the ifdef shouldn't be in the general code, but enclosed in a function, see 3fd66df4813d1410c1a6187c80e3a23395b14aed
Yes, it can be useful. Let's see how the other permission problem I have fares and if it's problematic, then we'll go the fakeroot route.
Otherwise, at least two people have agreed that allowing sssd.sssd is OK and I'd be glad to do that change.
Nick
On (14/01/15 22:28), Nikolai Kondrashov wrote:
On 01/14/2015 10:06 PM, Jakub Hrozek wrote:
On Wed, Jan 14, 2015 at 07:09:07PM +0100, Lukas Slebodnik wrote:
On (14/01/15 15:54), Jakub Hrozek wrote:
On Wed, Jan 14, 2015 at 09:48:06AM -0500, Simo Sorce wrote:
On Wed, 14 Jan 2015 16:08:33 +0200 Nikolai Kondrashov Nikolai.Kondrashov@redhat.com 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.
Uhmmm though problem, I think, for this very special case, we may want an env var that allows the code to relax permission/ownership checking on the config file.
I do not generally like magic env variables, and we should have an option to compile this support out perhaps, but I see no other sane way short of intercepting stat() and faking permission/ownership only for this case.
+1 we already have some other cases where we have #ifdef UNIT_TESTS
And I hate them because in most cases it means that code stink. (But it would take a lot of effort to fix it)
an environment variable with sufficiently weird name to avoid accidental conflicts sounds like a good idea
We have a ticket for removing usage of env variable from *_child. I do not see any benefit from adding env just for tests.
Using fakeroot is much better solution then adding hack with env variables.
BTW fakeroot provides a fake root environment by means of LD_PRELOAD. The only disadvantage of fakeroot is that is not available on all platforms. (but there is not problem to prepare COPR repo)
So basically there is not a big difference between fakeroot and other cwrap packages.
I admit I know very little about fakeroot, but is it going to be useful except this one problem?
If yes, then fine, but if it's just about ownership of this single file, then an environment variable or an ifdef is just easier. I think it goes without saying that the ifdef shouldn't be in the general code, but enclosed in a function, see 3fd66df4813d1410c1a6187c80e3a23395b14aed
Yes, it can be useful. Let's see how the other permission problem I have fares and if it's problematic, then we'll go the fakeroot route.
Otherwise, at least two people have agreed that allowing sssd.sssd is OK and I'd be glad to do that change.
IIRC simo insisted on ownership of sssd.conf to stay root:root So two people needn't be enough :-)
I cannot find it in mails. There were many threads related to non-root patches.
LS
On 01/14/2015 10:55 PM, Lukas Slebodnik wrote:
On (14/01/15 22:28), Nikolai Kondrashov wrote:
On 01/14/2015 10:06 PM, Jakub Hrozek wrote:
On Wed, Jan 14, 2015 at 07:09:07PM +0100, Lukas Slebodnik wrote:
On (14/01/15 15:54), Jakub Hrozek wrote:
On Wed, Jan 14, 2015 at 09:48:06AM -0500, Simo Sorce wrote:
On Wed, 14 Jan 2015 16:08:33 +0200 Nikolai Kondrashov Nikolai.Kondrashov@redhat.com 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.
Uhmmm though problem, I think, for this very special case, we may want an env var that allows the code to relax permission/ownership checking on the config file.
I do not generally like magic env variables, and we should have an option to compile this support out perhaps, but I see no other sane way short of intercepting stat() and faking permission/ownership only for this case.
+1 we already have some other cases where we have #ifdef UNIT_TESTS
And I hate them because in most cases it means that code stink. (But it would take a lot of effort to fix it)
an environment variable with sufficiently weird name to avoid accidental conflicts sounds like a good idea
We have a ticket for removing usage of env variable from *_child. I do not see any benefit from adding env just for tests.
Using fakeroot is much better solution then adding hack with env variables.
BTW fakeroot provides a fake root environment by means of LD_PRELOAD. The only disadvantage of fakeroot is that is not available on all platforms. (but there is not problem to prepare COPR repo)
So basically there is not a big difference between fakeroot and other cwrap packages.
I admit I know very little about fakeroot, but is it going to be useful except this one problem?
If yes, then fine, but if it's just about ownership of this single file, then an environment variable or an ifdef is just easier. I think it goes without saying that the ifdef shouldn't be in the general code, but enclosed in a function, see 3fd66df4813d1410c1a6187c80e3a23395b14aed
Yes, it can be useful. Let's see how the other permission problem I have fares and if it's problematic, then we'll go the fakeroot route.
Otherwise, at least two people have agreed that allowing sssd.sssd is OK and I'd be glad to do that change.
IIRC simo insisted on ownership of sssd.conf to stay root:root So two people needn't be enough :-)
I cannot find it in mails. There were many threads related to non-root patches.
OK, I'll ask him directly :)
Nick
On 01/14/2015 08:09 PM, Lukas Slebodnik wrote:
Using fakeroot is much better solution then adding hack with env variables.
BTW fakeroot provides a fake root environment by means of LD_PRELOAD. The only disadvantage of fakeroot is that is not available on all platforms. (but there is not problem to prepare COPR repo)
So basically there is not a big difference between fakeroot and other cwrap packages.
Just an update: it's not all rainbows in the fakeroot land either. It's not wrapping open()/create(). That means that all files sssd creates belong to root under fakeroot (even though it can chown them to anything), which is not compatible with --with-sssd-user.
I'm also having some problem starting sssd as root under fakeroot. Something to do with D-BUS sockets probably.
Will keep digging.
Nick
On (16/01/15 14:22), Nikolai Kondrashov wrote:
On 01/14/2015 08:09 PM, Lukas Slebodnik wrote:
Using fakeroot is much better solution then adding hack with env variables.
BTW fakeroot provides a fake root environment by means of LD_PRELOAD. The only disadvantage of fakeroot is that is not available on all platforms. (but there is not problem to prepare COPR repo)
So basically there is not a big difference between fakeroot and other cwrap packages.
Just an update: it's not all rainbows in the fakeroot land either. It's not wrapping open()/create(). That means that all files sssd creates belong to root under fakeroot (even though it can chown them to anything), which is not compatible with --with-sssd-user.
I'm also having some problem starting sssd as root under fakeroot. Something to do with D-BUS sockets probably.
We do not use dbus communication directly (execpt sssd_ifp. We use unix sockets and libdbus is used just for marshaling.
Will keep digging.
Feel free to send mails to sssd-devel with any problem.
LS
On 01/16/2015 02:48 PM, Lukas Slebodnik wrote:
On (16/01/15 14:22), Nikolai Kondrashov wrote:
On 01/14/2015 08:09 PM, Lukas Slebodnik wrote:
Using fakeroot is much better solution then adding hack with env variables.
BTW fakeroot provides a fake root environment by means of LD_PRELOAD. The only disadvantage of fakeroot is that is not available on all platforms. (but there is not problem to prepare COPR repo)
So basically there is not a big difference between fakeroot and other cwrap packages.
Just an update: it's not all rainbows in the fakeroot land either. It's not wrapping open()/create(). That means that all files sssd creates belong to root under fakeroot (even though it can chown them to anything), which is not compatible with --with-sssd-user.
I'm also having some problem starting sssd as root under fakeroot. Something to do with D-BUS sockets probably.
We do not use dbus communication directly (execpt sssd_ifp. We use unix sockets and libdbus is used just for marshaling.
Ah, yes, I think I can see that now.
Will keep digging.
Feel free to send mails to sssd-devel with any problem.
Thank you, Lukas.
I think this has something to do with my problems:
stat("/root/.dbus-keyrings", 0x7fff248f2490) = -1 EACCES (Permission denied)
Nick
On Fri, Jan 16, 2015 at 06:40:51PM +0200, Nikolai Kondrashov wrote:
On 01/16/2015 02:48 PM, Lukas Slebodnik wrote:
On (16/01/15 14:22), Nikolai Kondrashov wrote:
On 01/14/2015 08:09 PM, Lukas Slebodnik wrote:
Using fakeroot is much better solution then adding hack with env variables.
BTW fakeroot provides a fake root environment by means of LD_PRELOAD. The only disadvantage of fakeroot is that is not available on all platforms. (but there is not problem to prepare COPR repo)
So basically there is not a big difference between fakeroot and other cwrap packages.
Just an update: it's not all rainbows in the fakeroot land either. It's not wrapping open()/create(). That means that all files sssd creates belong to root under fakeroot (even though it can chown them to anything), which is not compatible with --with-sssd-user.
I'm also having some problem starting sssd as root under fakeroot. Something to do with D-BUS sockets probably.
We do not use dbus communication directly (execpt sssd_ifp. We use unix sockets and libdbus is used just for marshaling.
Ah, yes, I think I can see that now.
Will keep digging.
Feel free to send mails to sssd-devel with any problem.
Thank you, Lukas.
I think this has something to do with my problems:
stat("/root/.dbus-keyrings", 0x7fff248f2490) = -1 EACCES (Permission denied)
Which process does this? Can you post more context?
The sbus communication is peer-to-peer..
On 01/16/2015 06:54 PM, Jakub Hrozek wrote:
On Fri, Jan 16, 2015 at 06:40:51PM +0200, Nikolai Kondrashov wrote:
On 01/16/2015 02:48 PM, Lukas Slebodnik wrote:
On (16/01/15 14:22), Nikolai Kondrashov wrote:
On 01/14/2015 08:09 PM, Lukas Slebodnik wrote:
Using fakeroot is much better solution then adding hack with env variables.
BTW fakeroot provides a fake root environment by means of LD_PRELOAD. The only disadvantage of fakeroot is that is not available on all platforms. (but there is not problem to prepare COPR repo)
So basically there is not a big difference between fakeroot and other cwrap packages.
Just an update: it's not all rainbows in the fakeroot land either. It's not wrapping open()/create(). That means that all files sssd creates belong to root under fakeroot (even though it can chown them to anything), which is not compatible with --with-sssd-user.
I'm also having some problem starting sssd as root under fakeroot. Something to do with D-BUS sockets probably.
We do not use dbus communication directly (execpt sssd_ifp. We use unix sockets and libdbus is used just for marshaling.
Ah, yes, I think I can see that now.
Will keep digging.
Feel free to send mails to sssd-devel with any problem.
Thank you, Lukas.
I think this has something to do with my problems:
stat("/root/.dbus-keyrings", 0x7fff248f2490) = -1 EACCES (Permission denied)Which process does this? Can you post more context?
The sbus communication is peer-to-peer..
sssd and sssd_be. I've got all the logs and straces and whatever. Basically, it seems D-Bus is trying to store its keyring in ~/.dbus-keyrings directory. With user being root it naturally tries to store it in /root/.dbus-keyrings.
Actually, as we have control of passswd database, we can put root's home anywhere. I'll try that.
Nick
On 01/16/2015 08:29 PM, Nikolai Kondrashov wrote:
On 01/16/2015 06:54 PM, Jakub Hrozek wrote:
On Fri, Jan 16, 2015 at 06:40:51PM +0200, Nikolai Kondrashov wrote:
On 01/16/2015 02:48 PM, Lukas Slebodnik wrote:
On (16/01/15 14:22), Nikolai Kondrashov wrote:
On 01/14/2015 08:09 PM, Lukas Slebodnik wrote:
Using fakeroot is much better solution then adding hack with env variables.
BTW fakeroot provides a fake root environment by means of LD_PRELOAD. The only disadvantage of fakeroot is that is not available on all platforms. (but there is not problem to prepare COPR repo)
So basically there is not a big difference between fakeroot and other cwrap packages.
Just an update: it's not all rainbows in the fakeroot land either. It's not wrapping open()/create(). That means that all files sssd creates belong to root under fakeroot (even though it can chown them to anything), which is not compatible with --with-sssd-user.
I'm also having some problem starting sssd as root under fakeroot. Something to do with D-BUS sockets probably.
We do not use dbus communication directly (execpt sssd_ifp. We use unix sockets and libdbus is used just for marshaling.
Ah, yes, I think I can see that now.
Will keep digging.
Feel free to send mails to sssd-devel with any problem.
Thank you, Lukas.
I think this has something to do with my problems:
stat("/root/.dbus-keyrings", 0x7fff248f2490) = -1 EACCES (Permission denied)Which process does this? Can you post more context?
The sbus communication is peer-to-peer..
sssd and sssd_be. I've got all the logs and straces and whatever. Basically, it seems D-Bus is trying to store its keyring in ~/.dbus-keyrings directory. With user being root it naturally tries to store it in /root/.dbus-keyrings.
Actually, as we have control of passswd database, we can put root's home anywhere. I'll try that.
Yep, that helped.
However, I wonder does it really put its keyring into root's home during normal operation and if that's what we want.
Nick
On Fri, Jan 16, 2015 at 10:55:37PM +0200, Nikolai Kondrashov wrote:
On 01/16/2015 08:29 PM, Nikolai Kondrashov wrote:
On 01/16/2015 06:54 PM, Jakub Hrozek wrote:
On Fri, Jan 16, 2015 at 06:40:51PM +0200, Nikolai Kondrashov wrote:
On 01/16/2015 02:48 PM, Lukas Slebodnik wrote:
On (16/01/15 14:22), Nikolai Kondrashov wrote:
On 01/14/2015 08:09 PM, Lukas Slebodnik wrote: >Using fakeroot is much better solution then adding hack with env variables. > >BTW fakeroot provides a fake root environment by means of LD_PRELOAD. >The only disadvantage of fakeroot is that is not available on all platforms. >(but there is not problem to prepare COPR repo) > >So basically there is not a big difference between fakeroot and other cwrap >packages.
Just an update: it's not all rainbows in the fakeroot land either. It's not wrapping open()/create(). That means that all files sssd creates belong to root under fakeroot (even though it can chown them to anything), which is not compatible with --with-sssd-user.
I'm also having some problem starting sssd as root under fakeroot. Something to do with D-BUS sockets probably.
We do not use dbus communication directly (execpt sssd_ifp. We use unix sockets and libdbus is used just for marshaling.
Ah, yes, I think I can see that now.
Will keep digging.
Feel free to send mails to sssd-devel with any problem.
Thank you, Lukas.
I think this has something to do with my problems:
stat("/root/.dbus-keyrings", 0x7fff248f2490) = -1 EACCES (Permission denied)Which process does this? Can you post more context?
The sbus communication is peer-to-peer..
sssd and sssd_be. I've got all the logs and straces and whatever. Basically, it seems D-Bus is trying to store its keyring in ~/.dbus-keyrings directory. With user being root it naturally tries to store it in /root/.dbus-keyrings.
Actually, as we have control of passswd database, we can put root's home anywhere. I'll try that.
Yep, that helped.
However, I wonder does it really put its keyring into root's home during normal operation and if that's what we want.
To be honest, this is a detail of D-Bus I don't know. Colin Walters might know better..
----- Original Message -----
From: "Nikolai Kondrashov" Nikolai.Kondrashov@redhat.com To: "Development of the System Security Services Daemon" sssd-devel@lists.fedorahosted.org Sent: Friday, January 16, 2015 7:29:53 PM Subject: Re: [SSSD] Config file ownership and cwrap tests
On 01/16/2015 06:54 PM, Jakub Hrozek wrote:
On Fri, Jan 16, 2015 at 06:40:51PM +0200, Nikolai Kondrashov wrote:
On 01/16/2015 02:48 PM, Lukas Slebodnik wrote:
On (16/01/15 14:22), Nikolai Kondrashov wrote:
On 01/14/2015 08:09 PM, Lukas Slebodnik wrote:
Using fakeroot is much better solution then adding hack with env variables.
BTW fakeroot provides a fake root environment by means of LD_PRELOAD. The only disadvantage of fakeroot is that is not available on all platforms. (but there is not problem to prepare COPR repo)
So basically there is not a big difference between fakeroot and other cwrap packages.
Just an update: it's not all rainbows in the fakeroot land either. It's not wrapping open()/create(). That means that all files sssd creates belong to root under fakeroot (even though it can chown them to anything), which is not compatible with --with-sssd-user.
I'm also having some problem starting sssd as root under fakeroot. Something to do with D-BUS sockets probably.
We do not use dbus communication directly (execpt sssd_ifp. We use unix sockets and libdbus is used just for marshaling.
Ah, yes, I think I can see that now.
Will keep digging.
Feel free to send mails to sssd-devel with any problem.
Thank you, Lukas.
I think this has something to do with my problems:
stat("/root/.dbus-keyrings", 0x7fff248f2490) = -1 EACCES (Permission denied)Which process does this? Can you post more context?
The sbus communication is peer-to-peer..
sssd and sssd_be. I've got all the logs and straces and whatever. Basically, it seems D-Bus is trying to store its keyring in ~/.dbus-keyrings directory. With user being root it naturally tries to store it in /root/.dbus-keyrings.
Actually, as we have control of passswd database, we can put root's home anywhere. I'll try that.
Erm... isn't that risky ? Other applications running as user "root" in parallel to what you're doing might trip over such a change... ... is there no way to override the keyring location (quick look at |dbus_keyring_new_homedir()| doesn't show any way... but maybe one of the DBus experts might know a way. If this fails there is always /proc/$pid/root/ which can AFAIK be overridden on a per-process basis (details on demand, I have to dig out how this works...)) ?
----
Bye, Roland
On 01/21/2015 01:54 PM, Roland Mainz wrote:
sssd and sssd_be. I've got all the logs and straces and whatever. Basically, it seems D-Bus is trying to store its keyring in ~/.dbus-keyrings directory. With user being root it naturally tries to store it in /root/.dbus-keyrings.
Actually, as we have control of passswd database, we can put root's home anywhere. I'll try that.
Erm... isn't that risky ? Other applications running as user "root" in parallel to what you're doing might trip over such a change...
No, we have the NSS module and passwd file location overridden with nss_wrapper for our test only. We're also running as a regular user, so we can't really change /etc/passwd.
... is there no way to override the keyring location (quick look at |dbus_keyring_new_homedir()| doesn't show any way... but maybe one of the DBus experts might know a way. If this fails there is always /proc/$pid/root/ which can AFAIK be overridden on a per-process basis (details on demand, I have to dig out how this works...)) ?
Yes, I looked at the code as well and couldn't find any way to change that.
Changing filesystem root would also require root privelegies and we don't have that. And then we don't want to haul the whole hierarchy that various programs we invoke might require.
Nick
----- Original Message -----
From: "Nikolai Kondrashov" Nikolai.Kondrashov@redhat.com To: "Development of the System Security Services Daemon" sssd-devel@lists.fedorahosted.org Sent: Friday, January 16, 2015 1:22:29 PM Subject: Re: [SSSD] Config file ownership and cwrap tests
On 01/14/2015 08:09 PM, Lukas Slebodnik wrote:
Using fakeroot is much better solution then adding hack with env variables.
BTW fakeroot provides a fake root environment by means of LD_PRELOAD. The only disadvantage of fakeroot is that is not available on all platforms. (but there is not problem to prepare COPR repo)
So basically there is not a big difference between fakeroot and other cwrap packages.
Just an update: it's not all rainbows in the fakeroot land either. It's not wrapping open()/create(). That means that all files sssd creates belong to root under fakeroot (even though it can chown them to anything), which is not compatible with --with-sssd-user.
I'm also having some problem starting sssd as root under fakeroot. Something to do with D-BUS sockets probably.
Does Fedora have union mounts (originally from Plan 9, AFAIK Linux calls this "unionfs" or "overlayfs") ? If "yes" then some stunts with unionfs and |chroot()| should be possible for testing. Let me know if I should dig-out the details...
----
Bye, Roland
On 01/21/2015 02:05 PM, Roland Mainz wrote:
----- Original Message -----
From: "Nikolai Kondrashov" Nikolai.Kondrashov@redhat.com To: "Development of the System Security Services Daemon" sssd-devel@lists.fedorahosted.org Sent: Friday, January 16, 2015 1:22:29 PM Subject: Re: [SSSD] Config file ownership and cwrap tests
On 01/14/2015 08:09 PM, Lukas Slebodnik wrote:
Using fakeroot is much better solution then adding hack with env variables.
BTW fakeroot provides a fake root environment by means of LD_PRELOAD. The only disadvantage of fakeroot is that is not available on all platforms. (but there is not problem to prepare COPR repo)
So basically there is not a big difference between fakeroot and other cwrap packages.
Just an update: it's not all rainbows in the fakeroot land either. It's not wrapping open()/create(). That means that all files sssd creates belong to root under fakeroot (even though it can chown them to anything), which is not compatible with --with-sssd-user.
I'm also having some problem starting sssd as root under fakeroot. Something to do with D-BUS sockets probably.
Does Fedora have union mounts (originally from Plan 9, AFAIK Linux calls this "unionfs" or "overlayfs") ? If "yes" then some stunts with unionfs and |chroot()| should be possible for testing. Let me know if I should dig-out the details...
I guess it does, but that would require a real root, which is against our requirements of running from within a "make check" as a regular user.
Nick
----- Original Message -----
From: "Nikolai Kondrashov" Nikolai.Kondrashov@redhat.com To: "Development of the System Security Services Daemon" sssd-devel@lists.fedorahosted.org Sent: Wednesday, January 21, 2015 1:19:57 PM Subject: Re: [SSSD] Config file ownership and cwrap tests
On 01/21/2015 02:05 PM, Roland Mainz wrote:
----- Original Message -----
From: "Nikolai Kondrashov" Nikolai.Kondrashov@redhat.com To: "Development of the System Security Services Daemon" sssd-devel@lists.fedorahosted.org Sent: Friday, January 16, 2015 1:22:29 PM Subject: Re: [SSSD] Config file ownership and cwrap tests
On 01/14/2015 08:09 PM, Lukas Slebodnik wrote:
Using fakeroot is much better solution then adding hack with env variables.
BTW fakeroot provides a fake root environment by means of LD_PRELOAD. The only disadvantage of fakeroot is that is not available on all platforms. (but there is not problem to prepare COPR repo)
So basically there is not a big difference between fakeroot and other cwrap packages.
Just an update: it's not all rainbows in the fakeroot land either. It's not wrapping open()/create(). That means that all files sssd creates belong to root under fakeroot (even though it can chown them to anything), which is not compatible with --with-sssd-user.
I'm also having some problem starting sssd as root under fakeroot. Something to do with D-BUS sockets probably.
Does Fedora have union mounts (originally from Plan 9, AFAIK Linux calls this "unionfs" or "overlayfs") ? If "yes" then some stunts with unionfs and |chroot()| should be possible for testing. Let me know if I should dig-out the details...
I guess it does, but that would require a real root, which is against our requirements of running from within a "make check" as a regular user.
setid (setuid/setgid) wrapper which does the { union mount, does |chroot()|, executes command in that environment } is no option ?
Another option would be to modify fakeroot and intercept |open()| and |creat()| ([1]) and replace it with calls to a virtual root via |openat()| (AFAIK this should be easy to do since we just put the virtual root's fd in front of the path and make the absolute paths relative to the virtual root (open issue is how to communicate the fd to child processes of fakeroot); but this is still not bullet-proof, e.g. anything which does a $ env - ... # will leave your fakeroot-jail and any /proc/-based path-relative filesystem accesses will fail, too) ...
[1]=(... and |openat()| and most of the other filesystem syscalls (AFAIK the list in http://svn.nrubsig.org/svn/people/gisburn/code/openat_emu/ast_map_fsat.h could be used as template))
----
Bye, Roland
On 01/21/2015 03:09 PM, Roland Mainz wrote:
----- Original Message -----
From: "Nikolai Kondrashov" Nikolai.Kondrashov@redhat.com To: "Development of the System Security Services Daemon" sssd-devel@lists.fedorahosted.org Sent: Wednesday, January 21, 2015 1:19:57 PM Subject: Re: [SSSD] Config file ownership and cwrap tests
On 01/21/2015 02:05 PM, Roland Mainz wrote:
----- Original Message -----
From: "Nikolai Kondrashov" Nikolai.Kondrashov@redhat.com To: "Development of the System Security Services Daemon" sssd-devel@lists.fedorahosted.org Sent: Friday, January 16, 2015 1:22:29 PM Subject: Re: [SSSD] Config file ownership and cwrap tests
On 01/14/2015 08:09 PM, Lukas Slebodnik wrote:
Using fakeroot is much better solution then adding hack with env variables.
BTW fakeroot provides a fake root environment by means of LD_PRELOAD. The only disadvantage of fakeroot is that is not available on all platforms. (but there is not problem to prepare COPR repo)
So basically there is not a big difference between fakeroot and other cwrap packages.
Just an update: it's not all rainbows in the fakeroot land either. It's not wrapping open()/create(). That means that all files sssd creates belong to root under fakeroot (even though it can chown them to anything), which is not compatible with --with-sssd-user.
I'm also having some problem starting sssd as root under fakeroot. Something to do with D-BUS sockets probably.
Does Fedora have union mounts (originally from Plan 9, AFAIK Linux calls this "unionfs" or "overlayfs") ? If "yes" then some stunts with unionfs and |chroot()| should be possible for testing. Let me know if I should dig-out the details...
I guess it does, but that would require a real root, which is against our requirements of running from within a "make check" as a regular user.
setid (setuid/setgid) wrapper which does the { union mount, does |chroot()|, executes command in that environment } is no option ?
It could be a last resort option, but I think we're better off not requiring any special packages just for "make check" and we can do away with modifying sssd itself to be more flexible. I don't think there are any real technical obstacles there.
As such it seems it works with fakeroot, uid_wrapper and nss_wrapper, which should be good for the start.
Another option would be to modify fakeroot and intercept |open()| and |creat()| ([1]) and replace it with calls to a virtual root via |openat()| (AFAIK this should be easy to do since we just put the virtual root's fd in front of the path and make the absolute paths relative to the virtual root (open issue is how to communicate the fd to child processes of fakeroot);
Fakeroot doesn't intercept open()/creat() because it was seen creating problems with libc upgrades and we would be in a special risk here testing on Debian Testing and Fedora Rawhide. At least some of the virtual root stuff is done by fakechroot, but that is still not available everywhere and so is close to a custom package solution. Then, again, we don't want to create our own chroot environment (fake or otherwise), if we can.
but this is still not bullet-proof, e.g. anything which does a $ env - ... # will leave your fakeroot-jail and any /proc/-based path-relative filesystem accesses will fail, too) ...
Apart from this being a too burdensome solution, I think it would have been sufficient.
[1]=(... and |openat()| and most of the other filesystem syscalls (AFAIK the list in http://svn.nrubsig.org/svn/people/gisburn/code/openat_emu/ast_map_fsat.h could be used as template))
Thanks for the suggestions, Roland!
Nick
----- Original Message -----
From: "Nikolai Kondrashov" Nikolai.Kondrashov@redhat.com To: "Development of the System Security Services Daemon" sssd-devel@lists.fedorahosted.org Sent: Wednesday, January 21, 2015 2:47:57 PM Subject: Re: [SSSD] Config file ownership and cwrap tests
On 01/21/2015 03:09 PM, Roland Mainz wrote:
----- Original Message -----
From: "Nikolai Kondrashov" Nikolai.Kondrashov@redhat.com To: "Development of the System Security Services Daemon" sssd-devel@lists.fedorahosted.org Sent: Wednesday, January 21, 2015 1:19:57 PM Subject: Re: [SSSD] Config file ownership and cwrap tests
[snip]
Does Fedora have union mounts (originally from Plan 9, AFAIK Linux calls this "unionfs" or "overlayfs") ? If "yes" then some stunts with unionfs and |chroot()| should be possible for testing. Let me know if I should |dig-out the details...
I guess it does, but that would require a real root, which is against our requirements of running from within a "make check" as a regular user.
setid (setuid/setgid) wrapper which does the { union mount, does |chroot()|, executes command in that environment } is no option ?
It could be a last resort option, but I think we're better off not requiring any special packages just for "make check" and we can do away with modifying sssd itself to be more flexible. I don't think there are any real technical obstacles there.
As such it seems it works with fakeroot, uid_wrapper and nss_wrapper, which should be good for the start.
OK...
Another option would be to modify fakeroot and intercept |open()| and |creat()| ([1]) and replace it with calls to a virtual root via |openat()| (AFAIK this should be easy to do since we just put the virtual root's fd in front of the path and make the absolute paths relative to the virtual root (open issue is how to communicate the fd to child processes of fakeroot);
Fakeroot doesn't intercept open()/creat() because it was seen creating problems with libc upgrades
Why ? AFAIK (if I get this right) the problem is "loops inside the emulation code" and the issue that glibc doesn't follow the UNIX convention of separating internal (libc-to-libc) vs. external libc calls... but that can AFAIK be solved via a per-thread flag (|pthread_key_create()| can be used to keep the code portable; two issues need to be worked out: 1. syscalls inside signal handlers and 2. thread cancellation points) to indicate that we're inside the wrapper mechanism.
and we would be in a special risk here testing on Debian Testing and Fedora Rawhide.
What is the problem with testing on Debian ?
At least some of the virtual root stuff is done by fakechroot, but that is still not available everywhere and so is close to a custom package solution. Then, again, we don't want to create our own chroot environment (fake or otherwise), if we can.
OK... next crazy option would be testing via NFS root (see http://fedoraproject.org/wiki/Dracut) and qemu... I did lots of work related to this for testing Kerberos5 in a isolated multi-machine environment which can be fully controlled by scripts (without having to own multiple machines) and it seems to work (drawback is that you need to invest lots of time (and cursing) to have all the pieces together, but once you're past that point it works quite good).
----
Bye, Roland
On 01/21/2015 04:20 PM, Roland Mainz wrote:
----- Original Message -----
From: "Nikolai Kondrashov" Nikolai.Kondrashov@redhat.com To: "Development of the System Security Services Daemon" sssd-devel@lists.fedorahosted.org Sent: Wednesday, January 21, 2015 2:47:57 PM Subject: Re: [SSSD] Config file ownership and cwrap tests
On 01/21/2015 03:09 PM, Roland Mainz wrote:
Another option would be to modify fakeroot and intercept |open()| and |creat()| ([1]) and replace it with calls to a virtual root via |openat()| (AFAIK this should be easy to do since we just put the virtual root's fd in front of the path and make the absolute paths relative to the virtual root (open issue is how to communicate the fd to child processes of fakeroot);
Fakeroot doesn't intercept open()/creat() because it was seen creating problems with libc upgrades
Why ? AFAIK (if I get this right) the problem is "loops inside the emulation code" and the issue that glibc doesn't follow the UNIX convention of separating internal (libc-to-libc) vs. external libc calls... but that can AFAIK be solved via a per-thread flag (|pthread_key_create()| can be used to keep the code portable; two issues need to be worked out: 1. syscalls inside signal handlers and 2. thread cancellation points) to indicate that we're inside the wrapper mechanism.
That could, perhaps, be a solution to the particular hairness of wrapping libc which calls itself. However, that would still be a requirement of a special package (in this case modified fakeroot) for our "make check" run, which we would like to avoid.
I think we should be able to manage with stock fakeroot for sssd configured for running as root and no fakeroot otherwise.
and we would be in a special risk here testing on Debian Testing and Fedora Rawhide.
What is the problem with testing on Debian ?
No problem except the higher chance of a libc upgrade, similarly to Fedora Rawhide.
At least some of the virtual root stuff is done by fakechroot, but that is still not available everywhere and so is close to a custom package solution. Then, again, we don't want to create our own chroot environment (fake or otherwise), if we can.
OK... next crazy option would be testing via NFS root (see http://fedoraproject.org/wiki/Dracut) and qemu... I did lots of work related to this for testing Kerberos5 in a isolated multi-machine environment which can be fully controlled by scripts (without having to own multiple machines) and it seems to work (drawback is that you need to invest lots of time (and cursing) to have all the pieces together, but once you're past that point it works quite good).
Woah, woah, that's definitely a crazy option :) We don't want to require running make check in a QEMU with NFS root :)
Otherwise I did some NFS root running during my embedded work and it worked well.
Nick
----- Original Message -----
From: "Nikolai Kondrashov" Nikolai.Kondrashov@redhat.com To: "Development of the System Security Services Daemon" sssd-devel@lists.fedorahosted.org Sent: Wednesday, January 21, 2015 3:49:39 PM Subject: Re: [SSSD] Config file ownership and cwrap tests
[snip]
Fakeroot doesn't intercept open()/creat() because it was seen creating problems with libc upgrades
Why ? AFAIK (if I get this right) the problem is "loops inside the emulation code" and the issue that glibc doesn't follow the UNIX convention of separating internal (libc-to-libc) vs. external libc calls... but that can AFAIK be solved via a per-thread flag (|pthread_key_create()| can be used to keep the code portable; two issues need to be worked out: 1. syscalls inside signal handlers and 2. thread cancellation points) to indicate that we're inside the wrapper mechanism.
That could, perhaps, be a solution to the particular hairness of wrapping libc which calls itself. However, that would still be a requirement of a special package (in this case modified fakeroot) for our "make check" run, which we would like to avoid.
... or add an option to "fakeroot" via patch (fix wrapper call loop detection, add optional |open()|/|openat()|/etc. wrappers), submit it to upstream and make that new option the minimum we need for testing (OKOK... it's at least a manweek of work and it'll take some months until the changes will bleed through into our stable repositories... ;-(( ) ...
I think we should be able to manage with stock fakeroot for sssd configured for running as root and no fakeroot otherwise.
and we would be in a special risk here testing on Debian Testing and Fedora Rawhide.
What is the problem with testing on Debian ?
No problem except the higher chance of a libc upgrade, similarly to Fedora Rawhide.
;-((
At least some of the virtual root stuff is done by fakechroot, but that is still not available everywhere and so is close to a custom package solution. Then, again, we don't want to create our own chroot environment (fake or otherwise), if we can.
OK... next crazy option would be testing via NFS root (see http://fedoraproject.org/wiki/Dracut) and qemu... I did lots of work related to this for testing Kerberos5 in a isolated multi-machine environment which can be fully controlled by scripts (without having to own multiple machines) and it seems to work (drawback is that you need to invest lots of time (and cursing) to have all the pieces together, but once you're past that point it works quite good).
Woah, woah, that's definitely a crazy option :)
You wanted testing as (pseudo-)"root" with standard packages and being compatible to all applications (real driving point would be to do tests with multiple machines) ...
We don't want to require running make check in a QEMU with NFS root :)
OK... ... then what about a minimum-size/effort approach: LD_PRELOAD wrapper which intercepts |open()|&co. to just redirect that single keyring access ?
----
Bye, Roland
On 01/21/2015 07:03 PM, Roland Mainz wrote:
----- Original Message -----
From: "Nikolai Kondrashov" Nikolai.Kondrashov@redhat.com To: "Development of the System Security Services Daemon" sssd-devel@lists.fedorahosted.org Sent: Wednesday, January 21, 2015 3:49:39 PM Subject: Re: [SSSD] Config file ownership and cwrap tests
[snip]
Fakeroot doesn't intercept open()/creat() because it was seen creating problems with libc upgrades
Why ? AFAIK (if I get this right) the problem is "loops inside the emulation code" and the issue that glibc doesn't follow the UNIX convention of separating internal (libc-to-libc) vs. external libc calls... but that can AFAIK be solved via a per-thread flag (|pthread_key_create()| can be used to keep the code portable; two issues need to be worked out: 1. syscalls inside signal handlers and 2. thread cancellation points) to indicate that we're inside the wrapper mechanism.
That could, perhaps, be a solution to the particular hairness of wrapping libc which calls itself. However, that would still be a requirement of a special package (in this case modified fakeroot) for our "make check" run, which we would like to avoid.
... or add an option to "fakeroot" via patch (fix wrapper call loop detection, add optional |open()|/|openat()|/etc. wrappers), submit it to upstream and make that new option the minimum we need for testing (OKOK... it's at least a manweek of work and it'll take some months until the changes will bleed through into our stable repositories... ;-(( ) ...
Yeah...
At least some of the virtual root stuff is done by fakechroot, but that is still not available everywhere and so is close to a custom package solution. Then, again, we don't want to create our own chroot environment (fake or otherwise), if we can.
OK... next crazy option would be testing via NFS root (see http://fedoraproject.org/wiki/Dracut) and qemu... I did lots of work related to this for testing Kerberos5 in a isolated multi-machine environment which can be fully controlled by scripts (without having to own multiple machines) and it seems to work (drawback is that you need to invest lots of time (and cursing) to have all the pieces together, but once you're past that point it works quite good).
Woah, woah, that's definitely a crazy option :)
You wanted testing as (pseudo-)"root" with standard packages and being compatible to all applications (real driving point would be to do tests with multiple machines) ...
Well, first of all we don't really want "all" aplications at the moment, just sssd and Python. The multiple machine integration testing in CI is in the plan, but it's a whole other can of worms and I think we can still do a lot with just cwrap on a single host.
We don't want to require running make check in a QEMU with NFS root :)
OK... ... then what about a minimum-size/effort approach: LD_PRELOAD wrapper which intercepts |open()|&co. to just redirect that single keyring access ?
That could work, but I already worked that around by moving the root's home directory :)
Thanks for brainstorming, Roland!
Nick
On 01/14/2015 04:48 PM, Simo Sorce wrote:
On Wed, 14 Jan 2015 16:08:33 +0200 Nikolai Kondrashov Nikolai.Kondrashov@redhat.com 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.
Uhmmm though problem, I think, for this very special case, we may want an env var that allows the code to relax permission/ownership checking on the config file.
Would there be a problem if we allow sssd.conf to belong to the user we're running under, as well? The daemons run under that user and CDB file is chowned to it anyway.
I do not generally like magic env variables, and we should have an option to compile this support out perhaps, but I see no other sane way short of intercepting stat() and faking permission/ownership only for this case.
I wouldn't like another magic variable either. Could we perhaps get away with fakeroot here? It doesn't seem to me that LDAP integration testing would be very much affected by the potential bugs that it would hide.
Thank you.
Nick
On 01/14/2015 10:00 AM, Nikolai Kondrashov wrote:
On 01/14/2015 04:48 PM, Simo Sorce wrote:
On Wed, 14 Jan 2015 16:08:33 +0200 Nikolai Kondrashov Nikolai.Kondrashov@redhat.com 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.
Uhmmm though problem, I think, for this very special case, we may want an env var that allows the code to relax permission/ownership checking on the config file.
Would there be a problem if we allow sssd.conf to belong to the user we're running under, as well? The daemons run under that user and CDB file is chowned to it anyway.
I do not generally like magic env variables, and we should have an option to compile this support out perhaps, but I see no other sane way short of intercepting stat() and faking permission/ownership only for this case.
I wouldn't like another magic variable either. Could we perhaps get away with fakeroot here? It doesn't seem to me that LDAP integration testing would be very much affected by the potential bugs that it would hide.
Thank you.
Nick _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
How about the following approach: Add a switch to SSSD called --allow-user=uid If the switch is provided allow sssd.conf to be readable to root or this user, i.e. check for both. If not provided then check for just root as we always do. Run tests as this user and pass this switch in case of make check.
Would that work?
On 01/14/2015 08:58 PM, Dmitri Pal wrote:
On 01/14/2015 10:00 AM, Nikolai Kondrashov wrote:
On 01/14/2015 04:48 PM, Simo Sorce wrote:
On Wed, 14 Jan 2015 16:08:33 +0200 Nikolai Kondrashov Nikolai.Kondrashov@redhat.com 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.
Uhmmm though problem, I think, for this very special case, we may want an env var that allows the code to relax permission/ownership checking on the config file.
Would there be a problem if we allow sssd.conf to belong to the user we're running under, as well? The daemons run under that user and CDB file is chowned to it anyway.
I do not generally like magic env variables, and we should have an option to compile this support out perhaps, but I see no other sane way short of intercepting stat() and faking permission/ownership only for this case.
I wouldn't like another magic variable either. Could we perhaps get away with fakeroot here? It doesn't seem to me that LDAP integration testing would be very much affected by the potential bugs that it would hide.
Thank you.
Nick _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
How about the following approach: Add a switch to SSSD called --allow-user=uid If the switch is provided allow sssd.conf to be readable to root or this user, i.e. check for both. If not provided then check for just root as we always do. Run tests as this user and pass this switch in case of make check.
Would that work?
Thank you. That would, of course work, and be acceptable WRT the integration tests, but to me this seems polluting sssd option namespace for a very superficial feature.
Nick
On 01/14/2015 02:17 PM, Nikolai Kondrashov wrote:
On 01/14/2015 08:58 PM, Dmitri Pal wrote:
On 01/14/2015 10:00 AM, Nikolai Kondrashov wrote:
On 01/14/2015 04:48 PM, Simo Sorce wrote:
On Wed, 14 Jan 2015 16:08:33 +0200 Nikolai Kondrashov Nikolai.Kondrashov@redhat.com 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.
Uhmmm though problem, I think, for this very special case, we may want an env var that allows the code to relax permission/ownership checking on the config file.
Would there be a problem if we allow sssd.conf to belong to the user we're running under, as well? The daemons run under that user and CDB file is chowned to it anyway.
I do not generally like magic env variables, and we should have an option to compile this support out perhaps, but I see no other sane way short of intercepting stat() and faking permission/ownership only for this case.
I wouldn't like another magic variable either. Could we perhaps get away with fakeroot here? It doesn't seem to me that LDAP integration testing would be very much affected by the potential bugs that it would hide.
Thank you.
Nick _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
How about the following approach: Add a switch to SSSD called --allow-user=uid If the switch is provided allow sssd.conf to be readable to root or this user, i.e. check for both. If not provided then check for just root as we always do. Run tests as this user and pass this switch in case of make check.
Would that work?
Thank you. That would, of course work, and be acceptable WRT the integration tests, but to me this seems polluting sssd option namespace for a very superficial feature.
Nick
But is probably the simplest couple dozen line patch which can be done in less time that we spend in this thread. :-) But allowing sssd.sssd. user to own the file is fine with me, however we would have to change the error message, man pages and docs. Sounds like more effort to me...
On Wed, Jan 14, 2015 at 05:00:40PM +0200, Nikolai Kondrashov wrote:
Would there be a problem if we allow sssd.conf to belong to the user we're running under, as well? The daemons run under that user and CDB file is chowned to it anyway.
In general, no, if the file was owned by sssd.sssd and the permissions were restrictive so that others have no privileges, then we don't really open up the permissions, because you either have to be the sssd user (impossible, its shell is /sbin/nologin) or root..
I don't recally precisely why we didn't allow that..I guess a combination of paranoina since the config file can contain a bind password and the fact that even error messages tell the user to chown file to root.root..
On 01/14/2015 05:00 PM, Nikolai Kondrashov wrote:
On 01/14/2015 04:48 PM, Simo Sorce wrote:
On Wed, 14 Jan 2015 16:08:33 +0200 Nikolai Kondrashov Nikolai.Kondrashov@redhat.com 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.
Uhmmm though problem, I think, for this very special case, we may want an env var that allows the code to relax permission/ownership checking on the config file.
Would there be a problem if we allow sssd.conf to belong to the user we're running under, as well? The daemons run under that user and CDB file is chowned to it anyway.
Simo, do you have anything against this? I.e. allowing sssd.conf to belong to sssd.sssd as well as to root.root?
Thank you.
Nick
On Thu, 15 Jan 2015 12:39:35 +0200 Nikolai Kondrashov Nikolai.Kondrashov@redhat.com wrote:
On 01/14/2015 05:00 PM, Nikolai Kondrashov wrote:
On 01/14/2015 04:48 PM, Simo Sorce wrote:
On Wed, 14 Jan 2015 16:08:33 +0200 Nikolai Kondrashov Nikolai.Kondrashov@redhat.com 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.
Uhmmm though problem, I think, for this very special case, we may want an env var that allows the code to relax permission/ownership checking on the config file.
Would there be a problem if we allow sssd.conf to belong to the user we're running under, as well? The daemons run under that user and CDB file is chowned to it anyway.
Simo, do you have anything against this? I.e. allowing sssd.conf to belong to sssd.sssd as well as to root.root?
The reason why the file is owned by root.root is so that the unprivileged components can't touch it.
Allowing sssd.sssd to own the file defeats this measure, so I do not really like it as the standard behavior, unless we decide we stop checking sssd.conf ownership and just let the admin do what they think is better.
If we do the latter then we can simply turn the check from a failure to a warning and we just ignore the warning in the tests.
Simo.
On 01/15/2015 06:41 PM, Simo Sorce wrote:
On Thu, 15 Jan 2015 12:39:35 +0200 Nikolai Kondrashov Nikolai.Kondrashov@redhat.com wrote:
On 01/14/2015 05:00 PM, Nikolai Kondrashov wrote:
On 01/14/2015 04:48 PM, Simo Sorce wrote:
On Wed, 14 Jan 2015 16:08:33 +0200 Nikolai Kondrashov Nikolai.Kondrashov@redhat.com 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.
Uhmmm though problem, I think, for this very special case, we may want an env var that allows the code to relax permission/ownership checking on the config file.
Would there be a problem if we allow sssd.conf to belong to the user we're running under, as well? The daemons run under that user and CDB file is chowned to it anyway.
Simo, do you have anything against this? I.e. allowing sssd.conf to belong to sssd.sssd as well as to root.root?
The reason why the file is owned by root.root is so that the unprivileged components can't touch it.
Allowing sssd.sssd to own the file defeats this measure, so I do not really like it as the standard behavior, unless we decide we stop checking sssd.conf ownership and just let the admin do what they think is better.
If we do the latter then we can simply turn the check from a failure to a warning and we just ignore the warning in the tests.
Got it, thank you Simo. However, wouldn't the unprivileged processes still have most of the information from the configuration file?
Nick
On Thu, 15 Jan 2015 19:43:18 +0200 Nikolai Kondrashov Nikolai.Kondrashov@redhat.com wrote:
On 01/15/2015 06:41 PM, Simo Sorce wrote:
On Thu, 15 Jan 2015 12:39:35 +0200 Nikolai Kondrashov Nikolai.Kondrashov@redhat.com wrote:
On 01/14/2015 05:00 PM, Nikolai Kondrashov wrote:
On 01/14/2015 04:48 PM, Simo Sorce wrote:
On Wed, 14 Jan 2015 16:08:33 +0200 Nikolai Kondrashov Nikolai.Kondrashov@redhat.com 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.
Uhmmm though problem, I think, for this very special case, we may want an env var that allows the code to relax permission/ownership checking on the config file.
Would there be a problem if we allow sssd.conf to belong to the user we're running under, as well? The daemons run under that user and CDB file is chowned to it anyway.
Simo, do you have anything against this? I.e. allowing sssd.conf to belong to sssd.sssd as well as to root.root?
The reason why the file is owned by root.root is so that the unprivileged components can't touch it.
Allowing sssd.sssd to own the file defeats this measure, so I do not really like it as the standard behavior, unless we decide we stop checking sssd.conf ownership and just let the admin do what they think is better.
If we do the latter then we can simply turn the check from a failure to a warning and we just ignore the warning in the tests.
Got it, thank you Simo. However, wouldn't the unprivileged processes still have most of the information from the configuration file?
The problem is not about reading info, the problem is not being able to write it back and affect other services in a privilege escalation attack or similar.
Simo.
On 01/15/2015 08:16 PM, Simo Sorce wrote:
On Thu, 15 Jan 2015 19:43:18 +0200 Nikolai Kondrashov Nikolai.Kondrashov@redhat.com wrote:
On 01/15/2015 06:41 PM, Simo Sorce wrote:
On Thu, 15 Jan 2015 12:39:35 +0200 Nikolai Kondrashov Nikolai.Kondrashov@redhat.com wrote:
Simo, do you have anything against this? I.e. allowing sssd.conf to belong to sssd.sssd as well as to root.root?
The reason why the file is owned by root.root is so that the unprivileged components can't touch it.
Allowing sssd.sssd to own the file defeats this measure, so I do not really like it as the standard behavior, unless we decide we stop checking sssd.conf ownership and just let the admin do what they think is better.
I would be in support of that solution.
If we do the latter then we can simply turn the check from a failure to a warning and we just ignore the warning in the tests.
Got it, thank you Simo. However, wouldn't the unprivileged processes still have most of the information from the configuration file?
The problem is not about reading info, the problem is not being able to write it back and affect other services in a privilege escalation attack or similar.
Understood. Thank you.
Nick
sssd-devel@lists.fedorahosted.org
-
Dmitri Pal -
Jakub Hrozek -
Lukas Slebodnik -
Nikolai Kondrashov -
Roland Mainz -
Simo Sorce