Hi,
to reproduce, set a SELinux label for a user. Log in as the user and observer the permissions of /etc/selinux/targeted/modules/active changing to 0600. As a result, even local semanage tools didn't work..
On 01/26/2015 06:18 PM, Jakub Hrozek wrote:
Hi,
to reproduce, set a SELinux label for a user. Log in as the user and observer the permissions of /etc/selinux/targeted/modules/active changing to 0600. As a result, even local semanage tools didn't work..
The patch works fine. I will wait for the CI to finish before I ack it. Just for the record, in my case the semanage tools worked even without this patch, but I could see the unwanted changes in the directory permissions - with this patch everything was OK.
Michal
On Mon, Jan 26, 2015 at 06:18:26PM +0100, Jakub Hrozek wrote:
Hi,
to reproduce, set a SELinux label for a user. Log in as the user and observer the permissions of /etc/selinux/targeted/modules/active changing to 0600. As a result, even local semanage tools didn't work..
From dbe42c9ca20df500d09949512b86c86f7b4ce7ce Mon Sep 17 00:00:00 2001 From: Jakub Hrozek jhrozek@redhat.com Date: Mon, 26 Jan 2015 16:55:42 +0100 Subject: [PATCH] SELINUX: Set permissive umask for selinux operations
https://fedorahosted.org/sssd/ticket/2563
libsemanage calls mkdir() and then requires that the directory is created with permissions 0700. That doesn't work well for programs like sssd that set umask to a very restrictive value (like 177).
src/util/sss_semanage.c | 29 ++++++++++++++++++++++++++--- 1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/src/util/sss_semanage.c b/src/util/sss_semanage.c index 3c566553f2085a696f79c5ee35ec6015824d56a6..4de0ce2bb4d52852cc7fa4df8a3e92b667c27c81 100644 --- a/src/util/sss_semanage.c +++ b/src/util/sss_semanage.c @@ -216,8 +216,8 @@ done: return ret; }
-int set_seuser(const char *login_name, const char *seuser_name,
const char *mls)
+int _set_seuser(const char *login_name, const char *seuser_name,
const char *mls)
would it be possilbe to make _set_seuser static as _del_seuser?
{ semanage_handle_t *handle = NULL; semanage_seuser_key_t *key = NULL; @@ -282,7 +282,19 @@ done: return ret; }
-int del_seuser(const char *login_name) +int set_seuser(const char *login_name, const char *seuser_name,
const char *mls)
+{
- mode_t old_mask;
- int ret;
- old_mask = umask(0);
- ret = _set_seuser(login_name, seuser_name, mls);
- umask(old_mask);
just a comment, please note that umask() will change the umask of the whole process. With asynchronous processing we should always make sure to change the umask only where it is needed.
bye, Sumit
- return ret;
+}
+static int _del_seuser(const char *login_name) { semanage_handle_t *handle = NULL; semanage_seuser_key_t *key = NULL; @@ -353,6 +365,17 @@ done: return ret; }
+int del_seuser(const char *login_name) +{
- mode_t old_mask;
- int ret;
- old_mask = umask(0);
- ret = _del_seuser(login_name);
- umask(old_mask);
- return ret;
+}
#else /* HAVE_SEMANAGE */ int set_seuser(const char *login_name, const char *seuser_name, const char *mls) -- 2.1.0
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Tue, Jan 27, 2015 at 10:20:17AM +0100, Sumit Bose wrote:
On Mon, Jan 26, 2015 at 06:18:26PM +0100, Jakub Hrozek wrote:
Hi,
to reproduce, set a SELinux label for a user. Log in as the user and observer the permissions of /etc/selinux/targeted/modules/active changing to 0600. As a result, even local semanage tools didn't work..
From dbe42c9ca20df500d09949512b86c86f7b4ce7ce Mon Sep 17 00:00:00 2001 From: Jakub Hrozek jhrozek@redhat.com Date: Mon, 26 Jan 2015 16:55:42 +0100 Subject: [PATCH] SELINUX: Set permissive umask for selinux operations
https://fedorahosted.org/sssd/ticket/2563
libsemanage calls mkdir() and then requires that the directory is created with permissions 0700. That doesn't work well for programs like sssd that set umask to a very restrictive value (like 177).
src/util/sss_semanage.c | 29 ++++++++++++++++++++++++++--- 1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/src/util/sss_semanage.c b/src/util/sss_semanage.c index 3c566553f2085a696f79c5ee35ec6015824d56a6..4de0ce2bb4d52852cc7fa4df8a3e92b667c27c81 100644 --- a/src/util/sss_semanage.c +++ b/src/util/sss_semanage.c @@ -216,8 +216,8 @@ done: return ret; }
-int set_seuser(const char *login_name, const char *seuser_name,
const char *mls)
+int _set_seuser(const char *login_name, const char *seuser_name,
const char *mls)
would it be possilbe to make _set_seuser static as _del_seuser?
Sure, will do.
{ semanage_handle_t *handle = NULL; semanage_seuser_key_t *key = NULL; @@ -282,7 +282,19 @@ done: return ret; }
-int del_seuser(const char *login_name) +int set_seuser(const char *login_name, const char *seuser_name,
const char *mls)
+{
- mode_t old_mask;
- int ret;
- old_mask = umask(0);
- ret = _set_seuser(login_name, seuser_name, mls);
- umask(old_mask);
just a comment, please note that umask() will change the umask of the whole process. With asynchronous processing we should always make sure to change the umask only where it is needed.
Yes, that's why the synchronous set function is enclosed in setting and then resetting umask. Do you think it's better to only enclose specific libsemanage functions according to which of them might create the directory? I was considering this, but on the other hand, I think we should treat libsemanage as a black box and don't depend too much on the implementation.
On Tue, Jan 27, 2015 at 10:45:20AM +0100, Jakub Hrozek wrote:
On Tue, Jan 27, 2015 at 10:20:17AM +0100, Sumit Bose wrote:
On Mon, Jan 26, 2015 at 06:18:26PM +0100, Jakub Hrozek wrote:
Hi,
to reproduce, set a SELinux label for a user. Log in as the user and observer the permissions of /etc/selinux/targeted/modules/active changing to 0600. As a result, even local semanage tools didn't work..
From dbe42c9ca20df500d09949512b86c86f7b4ce7ce Mon Sep 17 00:00:00 2001 From: Jakub Hrozek jhrozek@redhat.com Date: Mon, 26 Jan 2015 16:55:42 +0100 Subject: [PATCH] SELINUX: Set permissive umask for selinux operations
https://fedorahosted.org/sssd/ticket/2563
libsemanage calls mkdir() and then requires that the directory is created with permissions 0700. That doesn't work well for programs like sssd that set umask to a very restrictive value (like 177).
src/util/sss_semanage.c | 29 ++++++++++++++++++++++++++--- 1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/src/util/sss_semanage.c b/src/util/sss_semanage.c index 3c566553f2085a696f79c5ee35ec6015824d56a6..4de0ce2bb4d52852cc7fa4df8a3e92b667c27c81 100644 --- a/src/util/sss_semanage.c +++ b/src/util/sss_semanage.c @@ -216,8 +216,8 @@ done: return ret; }
-int set_seuser(const char *login_name, const char *seuser_name,
const char *mls)
+int _set_seuser(const char *login_name, const char *seuser_name,
const char *mls)
would it be possilbe to make _set_seuser static as _del_seuser?
Sure, will do.
{ semanage_handle_t *handle = NULL; semanage_seuser_key_t *key = NULL; @@ -282,7 +282,19 @@ done: return ret; }
-int del_seuser(const char *login_name) +int set_seuser(const char *login_name, const char *seuser_name,
const char *mls)
+{
- mode_t old_mask;
- int ret;
- old_mask = umask(0);
- ret = _set_seuser(login_name, seuser_name, mls);
- umask(old_mask);
just a comment, please note that umask() will change the umask of the whole process. With asynchronous processing we should always make sure to change the umask only where it is needed.
Yes, that's why the synchronous set function is enclosed in setting and then resetting umask. Do you think it's better to only enclose specific libsemanage functions according to which of them might create the directory? I was considering this, but on the other hand, I think we should treat libsemanage as a black box and don't depend too much on the implementation.
Alternatively, we could only set and reset the umask in the caller. That way, we would know that a short-lived selinux_child is changing umask.
That is safer, but risks that we forget next time..so at least we need to add a comment to the declaration in header.
On Tue, Jan 27, 2015 at 10:51:24AM +0100, Jakub Hrozek wrote:
Alternatively, we could only set and reset the umask in the caller. That way, we would know that a short-lived selinux_child is changing umask.
That is safer, but risks that we forget next time..so at least we need to add a comment to the declaration in header.
Attached is an alternate patch that only touches the umask in the short-lived process.
On Tue, Jan 27, 2015 at 11:31:58AM +0100, Jakub Hrozek wrote:
On Tue, Jan 27, 2015 at 10:51:24AM +0100, Jakub Hrozek wrote:
Alternatively, we could only set and reset the umask in the caller. That way, we would know that a short-lived selinux_child is changing umask.
That is safer, but risks that we forget next time..so at least we need to add a comment to the declaration in header.
Attached is an alternate patch that only touches the umask in the short-lived process.
I would prefer this version if it passes Michal's tests.
bye, Sumit
From 0d40464b1e9a555700349105c5e87b055e0286d6 Mon Sep 17 00:00:00 2001 From: Jakub Hrozek jhrozek@redhat.com Date: Tue, 27 Jan 2015 11:12:18 +0100 Subject: [PATCH] SELINUX: Set and reset umask when caling set_seuser from deamon code
src/providers/ipa/selinux_child.c | 14 +++++++++++++- src/util/util.h | 4 ++++ 2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/src/providers/ipa/selinux_child.c b/src/providers/ipa/selinux_child.c index 6390d43cbe4f3d352702493c156f93ca20b07a2f..ec47ed818efb3ebc93c780a2b0fe6d900e463f2c 100644 --- a/src/providers/ipa/selinux_child.c +++ b/src/providers/ipa/selinux_child.c @@ -135,6 +135,18 @@ static errno_t prepare_response(TALLOC_CTX *mem_ctx, return EOK; }
+static int sc_set_seuser(const char *login_name, const char *seuser_name,
const char *mls)
+{
- int ret;
- mode_t old_mask;
- old_mask = umask(0);
- ret = set_seuser(login_name, seuser_name, mls);
- umask(old_mask);
- return ret;
+}
int main(int argc, const char *argv[]) { int opt; @@ -256,7 +268,7 @@ int main(int argc, const char *argv[])
DEBUG(SSSDBG_TRACE_FUNC, "performing selinux operations\n");
- ret = set_seuser(ibuf->username, ibuf->seuser, ibuf->mls_range);
- ret = sc_set_seuser(ibuf->username, ibuf->seuser, ibuf->mls_range); if (ret != EOK) { DEBUG(SSSDBG_CRIT_FAILURE, "Cannot set SELinux login context.\n"); goto fail;
diff --git a/src/util/util.h b/src/util/util.h index 4ee9bad113299d8fb3eabebec508c2ab4c80d4e9..22d6ef0a4e1340346d3d2997313aab50410f9dc0 100644 --- a/src/util/util.h +++ b/src/util/util.h @@ -640,6 +640,10 @@ errno_t switch_creds(TALLOC_CTX *mem_ctx, errno_t restore_creds(struct sss_creds *saved_creds);
/* from sss_semanage.c */ +/* Please note that libsemange relies on files and directories created with
- certain permissions. Therefore the caller should make sure the umask is
- not too restricted (especially when called from the daemon code).
- */
int set_seuser(const char *login_name, const char *seuser_name, const char *mlsrange); int del_seuser(const char *login_name); -- 2.1.0
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On 01/27/2015 12:29 PM, Sumit Bose wrote:
On Tue, Jan 27, 2015 at 11:31:58AM +0100, Jakub Hrozek wrote:
On Tue, Jan 27, 2015 at 10:51:24AM +0100, Jakub Hrozek wrote:
Alternatively, we could only set and reset the umask in the caller. That way, we would know that a short-lived selinux_child is changing umask.
That is safer, but risks that we forget next time..so at least we need to add a comment to the declaration in header.
Attached is an alternate patch that only touches the umask in the short-lived process.
I would prefer this version if it passes Michal's tests.
bye, Sumit
Works for me. Ack,
Michal
----- Original Message -----
From: "Jakub Hrozek" jhrozek@redhat.com To: sssd-devel@lists.fedorahosted.org Sent: Tuesday, January 27, 2015 11:31:58 AM Subject: Re: [SSSD] [PATCH] SELINUX: Set permissive umask for selinux operations
On Tue, Jan 27, 2015 at 10:51:24AM +0100, Jakub Hrozek wrote:
Alternatively, we could only set and reset the umask in the caller. That way, we would know that a short-lived selinux_child is changing umask.
That is safer, but risks that we forget next time..so at least we need to add a comment to the declaration in header.
Attached is an alternate patch that only touches the umask in the short-lived process.
Which syscall exactly (strace dump, please) causes the original issue ? Maybe there is a way to do this without having to rely on |umask()| (using the |*at()| APIs or a later modification of the permissions) ...
----
Bye, Roland
----- Original Message -----
From: "Roland Mainz" rmainz@redhat.com To: "Development of the System Security Services Daemon" sssd-devel@lists.fedorahosted.org Sent: Tuesday, January 27, 2015 4:41:28 PM Subject: Re: [SSSD] [PATCH] SELINUX: Set permissive umask for selinux operations
----- Original Message -----
From: "Jakub Hrozek" jhrozek@redhat.com To: sssd-devel@lists.fedorahosted.org Sent: Tuesday, January 27, 2015 11:31:58 AM Subject: Re: [SSSD] [PATCH] SELINUX: Set permissive umask for selinux operations
On Tue, Jan 27, 2015 at 10:51:24AM +0100, Jakub Hrozek wrote:
Alternatively, we could only set and reset the umask in the caller. That way, we would know that a short-lived selinux_child is changing umask.
That is safer, but risks that we forget next time..so at least we need to add a comment to the declaration in header.
Attached is an alternate patch that only touches the umask in the short-lived process.
Which syscall exactly (strace dump, please) causes the original issue ? Maybe there is a way to do this without having to rely on |umask()| (using the |*at()| APIs or a later modification of the permissions) ...
I discussed this with jhrozek on IRC... basically libsemanage should fix the permissions after the |mkdir()| call like the mkdir(1) code in https://searchcode.com/codesearch/view/5481405/ line 160 ... but until they we have to stick with the |umask()| workaround (and praying that sssd never uses threads).
----
Bye, Roland
On Tue, Jan 27, 2015 at 11:07:01AM -0500, Roland Mainz wrote:
----- Original Message -----
From: "Roland Mainz" rmainz@redhat.com To: "Development of the System Security Services Daemon" sssd-devel@lists.fedorahosted.org Sent: Tuesday, January 27, 2015 4:41:28 PM Subject: Re: [SSSD] [PATCH] SELINUX: Set permissive umask for selinux operations
----- Original Message -----
From: "Jakub Hrozek" jhrozek@redhat.com To: sssd-devel@lists.fedorahosted.org Sent: Tuesday, January 27, 2015 11:31:58 AM Subject: Re: [SSSD] [PATCH] SELINUX: Set permissive umask for selinux operations
On Tue, Jan 27, 2015 at 10:51:24AM +0100, Jakub Hrozek wrote:
Alternatively, we could only set and reset the umask in the caller. That way, we would know that a short-lived selinux_child is changing umask.
That is safer, but risks that we forget next time..so at least we need to add a comment to the declaration in header.
Attached is an alternate patch that only touches the umask in the short-lived process.
Which syscall exactly (strace dump, please) causes the original issue ? Maybe there is a way to do this without having to rely on |umask()| (using the |*at()| APIs or a later modification of the permissions) ...
I discussed this with jhrozek on IRC... basically libsemanage should fix the permissions after the |mkdir()| call like the mkdir(1) code in https://searchcode.com/codesearch/view/5481405/ line 160 ... but until they we have to stick with the |umask()| workaround (and praying that sssd never uses threads).
I filed: https://bugzilla.redhat.com/show_bug.cgi?id=1186422 and: https://bugzilla.redhat.com/show_bug.cgi?id=1186431
against libsemanage. As discussed with Roland on IRC, I will add a URL of the bugzilla to a comment in selinux_child to make it clear that it's just a workaround for a bug, not a clean solution.
On Tue, Jan 27, 2015 at 05:25:36PM +0100, Jakub Hrozek wrote:
On Tue, Jan 27, 2015 at 11:07:01AM -0500, Roland Mainz wrote:
----- Original Message -----
From: "Roland Mainz" rmainz@redhat.com To: "Development of the System Security Services Daemon" sssd-devel@lists.fedorahosted.org Sent: Tuesday, January 27, 2015 4:41:28 PM Subject: Re: [SSSD] [PATCH] SELINUX: Set permissive umask for selinux operations
----- Original Message -----
From: "Jakub Hrozek" jhrozek@redhat.com To: sssd-devel@lists.fedorahosted.org Sent: Tuesday, January 27, 2015 11:31:58 AM Subject: Re: [SSSD] [PATCH] SELINUX: Set permissive umask for selinux operations
On Tue, Jan 27, 2015 at 10:51:24AM +0100, Jakub Hrozek wrote:
Alternatively, we could only set and reset the umask in the caller. That way, we would know that a short-lived selinux_child is changing umask.
That is safer, but risks that we forget next time..so at least we need to add a comment to the declaration in header.
Attached is an alternate patch that only touches the umask in the short-lived process.
Which syscall exactly (strace dump, please) causes the original issue ? Maybe there is a way to do this without having to rely on |umask()| (using the |*at()| APIs or a later modification of the permissions) ...
I discussed this with jhrozek on IRC... basically libsemanage should fix the permissions after the |mkdir()| call like the mkdir(1) code in https://searchcode.com/codesearch/view/5481405/ line 160 ... but until they we have to stick with the |umask()| workaround (and praying that sssd never uses threads).
I filed: https://bugzilla.redhat.com/show_bug.cgi?id=1186422 and: https://bugzilla.redhat.com/show_bug.cgi?id=1186431
against libsemanage. As discussed with Roland on IRC, I will add a URL of the bugzilla to a comment in selinux_child to make it clear that it's just a workaround for a bug, not a clean solution.
FYI, I'll push the attached patch. The only difference from the version Michal acked is the additional comment.
----- Original Message -----
From: "Jakub Hrozek" jhrozek@redhat.com To: sssd-devel@lists.fedorahosted.org Sent: Tuesday, January 27, 2015 5:38:57 PM Subject: Re: [SSSD] [PATCH] SELINUX: Set permissive umask for selinux operations
On Tue, Jan 27, 2015 at 05:25:36PM +0100, Jakub Hrozek wrote:
On Tue, Jan 27, 2015 at 11:07:01AM -0500, Roland Mainz wrote:
----- Original Message -----
From: "Roland Mainz" rmainz@redhat.com To: "Development of the System Security Services Daemon" sssd-devel@lists.fedorahosted.org Sent: Tuesday, January 27, 2015 4:41:28 PM Subject: Re: [SSSD] [PATCH] SELINUX: Set permissive umask for selinux operations
----- Original Message -----
From: "Jakub Hrozek" jhrozek@redhat.com To: sssd-devel@lists.fedorahosted.org Sent: Tuesday, January 27, 2015 11:31:58 AM Subject: Re: [SSSD] [PATCH] SELINUX: Set permissive umask for selinux operations
On Tue, Jan 27, 2015 at 10:51:24AM +0100, Jakub Hrozek wrote:
Alternatively, we could only set and reset the umask in the caller. That way, we would know that a short-lived selinux_child is changing umask.
That is safer, but risks that we forget next time..so at least we need to add a comment to the declaration in header.
Attached is an alternate patch that only touches the umask in the short-lived process.
Which syscall exactly (strace dump, please) causes the original issue ? Maybe there is a way to do this without having to rely on |umask()| (using the |*at()| APIs or a later modification of the permissions) ...
I discussed this with jhrozek on IRC... basically libsemanage should fix the permissions after the |mkdir()| call like the mkdir(1) code in https://searchcode.com/codesearch/view/5481405/ line 160 ... but until they we have to stick with the |umask()| workaround (and praying that sssd never uses threads).
I filed: https://bugzilla.redhat.com/show_bug.cgi?id=1186422 and: https://bugzilla.redhat.com/show_bug.cgi?id=1186431
against libsemanage. As discussed with Roland on IRC, I will add a URL of the bugzilla to a comment in selinux_child to make it clear that it's just a workaround for a bug, not a clean solution.
FYI, I'll push the attached patch. The only difference from the version Michal acked is the additional comment.
Thanks for the bug reference in the patch... the patch is r=rmainz@redhat.com ...
----
Bye, Roland
On Tue, Jan 27, 2015 at 11:42:27AM -0500, Roland Mainz wrote:
----- Original Message -----
From: "Jakub Hrozek" jhrozek@redhat.com To: sssd-devel@lists.fedorahosted.org Sent: Tuesday, January 27, 2015 5:38:57 PM Subject: Re: [SSSD] [PATCH] SELINUX: Set permissive umask for selinux operations
On Tue, Jan 27, 2015 at 05:25:36PM +0100, Jakub Hrozek wrote:
On Tue, Jan 27, 2015 at 11:07:01AM -0500, Roland Mainz wrote:
----- Original Message -----
From: "Roland Mainz" rmainz@redhat.com To: "Development of the System Security Services Daemon" sssd-devel@lists.fedorahosted.org Sent: Tuesday, January 27, 2015 4:41:28 PM Subject: Re: [SSSD] [PATCH] SELINUX: Set permissive umask for selinux operations
----- Original Message -----
From: "Jakub Hrozek" jhrozek@redhat.com To: sssd-devel@lists.fedorahosted.org Sent: Tuesday, January 27, 2015 11:31:58 AM Subject: Re: [SSSD] [PATCH] SELINUX: Set permissive umask for selinux operations
On Tue, Jan 27, 2015 at 10:51:24AM +0100, Jakub Hrozek wrote: > Alternatively, we could only set and reset the umask in the caller. > That > way, we would know that a short-lived selinux_child is changing > umask. > > That is safer, but risks that we forget next time..so at least we > need > to add a comment to the declaration in header.
Attached is an alternate patch that only touches the umask in the short-lived process.
Which syscall exactly (strace dump, please) causes the original issue ? Maybe there is a way to do this without having to rely on |umask()| (using the |*at()| APIs or a later modification of the permissions) ...
I discussed this with jhrozek on IRC... basically libsemanage should fix the permissions after the |mkdir()| call like the mkdir(1) code in https://searchcode.com/codesearch/view/5481405/ line 160 ... but until they we have to stick with the |umask()| workaround (and praying that sssd never uses threads).
I filed: https://bugzilla.redhat.com/show_bug.cgi?id=1186422 and: https://bugzilla.redhat.com/show_bug.cgi?id=1186431
against libsemanage. As discussed with Roland on IRC, I will add a URL of the bugzilla to a comment in selinux_child to make it clear that it's just a workaround for a bug, not a clean solution.
FYI, I'll push the attached patch. The only difference from the version Michal acked is the additional comment.
Thanks for the bug reference in the patch... the patch is r=rmainz@redhat.com ...
Pushed upstream: * master: 8f78b6442f3176ee43aa06704a3adb9f4ac625d6 * sssd-1-12: b8894eb53017af67224d05470d2cdd2a65070a41
On Tue, Jan 27, 2015 at 10:41:28AM -0500, Roland Mainz wrote:
----- Original Message -----
From: "Jakub Hrozek" jhrozek@redhat.com To: sssd-devel@lists.fedorahosted.org Sent: Tuesday, January 27, 2015 11:31:58 AM Subject: Re: [SSSD] [PATCH] SELINUX: Set permissive umask for selinux operations
On Tue, Jan 27, 2015 at 10:51:24AM +0100, Jakub Hrozek wrote:
Alternatively, we could only set and reset the umask in the caller. That way, we would know that a short-lived selinux_child is changing umask.
That is safer, but risks that we forget next time..so at least we need to add a comment to the declaration in header.
Attached is an alternate patch that only touches the umask in the short-lived process.
Which syscall exactly (strace dump, please) causes the original issue ?
mkdir(2)
Maybe there is a way to do this without having to rely on |umask()| (using the |*at()| APIs or a later modification of the permissions) ...
We have no control over what libsemanage does, unfortunately.
sssd-devel@lists.fedorahosted.org