[SSSD] [sssd PR#991][+Waiting for review] Two fixes for wait-for-card feature
URL: https://github.com/SSSD/sssd/pull/991 Title: #991: Two fixes for wait-for-card feature Label: +Waiting for review ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
[SSSD] [sssd PR#991][opened] Two fixes for wait-for-card feature
URL: https://github.com/SSSD/sssd/pull/991
Author: sumit-bose
Title: #991: Two fixes for wait-for-card feature
Action: opened
PR body:
"""
Some privileged services like e.g. might only call with UID 0 but with a
different GID. This patch removes the GID 0 requirement to access to
private PAM socket so that e.g. gdm can use the wait-for-card option.
Some implementations of C_WaitForSlotEvent() might return even if no card
was inserted. So it has to be checked if a card is really present.
Resolves: https://pagure.io/SSSD/sssd/issue/4159
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/991/head:pr991
git checkout pr991
From 88c6236a2e1fc1194504984d497792f19c63f65a Mon Sep 17 00:00:00 2001
From: Sumit Bose
Date: Thu, 30 Jan 2020 13:14:14 +0100
Subject: [PATCH 1/2] p11_child: check if card is present in wait_for_card()
Some implementations of C_WaitForSlotEvent() might return even if no
card was inserted. So it has to be checked if a card is really present.
Resolves: https://pagure.io/SSSD/sssd/issue/4159
---
src/p11_child/p11_child_openssl.c | 47 ---
1 file changed, 25 insertions(+), 22 deletions(-)
diff --git a/src/p11_child/p11_child_openssl.c b/src/p11_child/p11_child_openssl.c
index 56601b1179..2957156127 100644
--- a/src/p11_child/p11_child_openssl.c
+++ b/src/p11_child/p11_child_openssl.c
@@ -1546,35 +1546,38 @@ static errno_t wait_for_card(CK_FUNCTION_LIST *module, CK_SLOT_ID *slot_id)
CK_RV rv;
CK_SLOT_INFO info;
-rv = module->C_WaitForSlotEvent(wait_flags, slot_id, NULL);
-if (rv != CKR_OK) {
-if (rv != CKR_FUNCTION_NOT_SUPPORTED) {
+do {
+rv = module->C_WaitForSlotEvent(wait_flags, slot_id, NULL);
+if (rv != CKR_OK && rv != CKR_FUNCTION_NOT_SUPPORTED) {
DEBUG(SSSDBG_OP_FAILURE,
"C_WaitForSlotEvent failed [%lu][%s].\n",
rv, p11_kit_strerror(rv));
return EIO;
}
-/* Poor man's wait */
-do {
+if (rv == CKR_FUNCTION_NOT_SUPPORTED) {
+/* Poor man's wait */
sleep(10);
-rv = module->C_GetSlotInfo(*slot_id, &info);
-if (rv != CKR_OK) {
-DEBUG(SSSDBG_OP_FAILURE, "C_GetSlotInfo failed\n");
-return EIO;
-}
-DEBUG(SSSDBG_TRACE_ALL,
- "Description [%s] Manufacturer [%s] flags [%lu] "
- "removable [%s] token present [%s].\n",
- info.slotDescription, info.manufacturerID, info.flags,
- (info.flags & CKF_REMOVABLE_DEVICE) ? "true": "false",
- (info.flags & CKF_TOKEN_PRESENT) ? "true": "false");
-if ((info.flags & CKF_REMOVABLE_DEVICE)
-&& (info.flags & CKF_TOKEN_PRESENT)) {
-break;
-}
-} while (true);
-}
+}
+
+rv = module->C_GetSlotInfo(*slot_id, &info);
+if (rv != CKR_OK) {
+DEBUG(SSSDBG_OP_FAILURE, "C_GetSlotInfo failed\n");
+return EIO;
+}
+DEBUG(SSSDBG_TRACE_ALL,
+ "Description [%s] Manufacturer [%s] flags [%lu] "
+ "removable [%s] token present [%s].\n",
+ info.slotDescription, info.manufacturerID, info.flags,
+ (info.flags & CKF_REMOVABLE_DEVICE) ? "true": "false",
+ (info.flags & CKF_TOKEN_PRESENT) ? "true": "false");
+
+/* Check if really a token is present */
+if ((info.flags & CKF_REMOVABLE_DEVICE)
+&& (info.flags & CKF_TOKEN_PRESENT)) {
+break;
+}
+} while (true);
return EOK;
}
From 6c42d6e5e482b10d05c048280de1aaa6995edae6 Mon Sep 17 00:00:00 2001
From: Sumit Bose
Date: Thu, 6 Feb 2020 14:50:23 +0100
Subject: [PATCH 2/2] PAM client: only require UID 0 for private socket
Some privileged services like e.g. might only call with UID 0 but with a
different GID. This patch removes the GID 0 requirement to access to
private PAM socket so that e.g. gdm can use the wait-for-card option.
Resolves: https://pagure.io/SSSD/sssd/issue/4159
---
src/sss_client/common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/sss_client/common.c b/src/sss_client/common.c
index 270ca8b541..902438c866 100644
--- a/src/sss_client/common.c
+++ b/src/sss_client/common.c
@@ -910,8 +910,8 @@ int sss_pam_make_request(enum sss_cli_command cmd,
goto out;
}
-/* only root shall use the privileged pipe */
-if (getuid() == 0 && getgid() == 0) {
+/* only UID 0 shall use the privileged pipe */
+if (getuid() == 0) {
socket_name = SSS_PAM_PRIV_SOCKET_NAME;
errno = 0;
statret = stat(socket_name, &stat_buf);
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedo
[SSSD] Re: KCM notifications
On Thu, 2020-02-20 at 11:18 +0100, Pavel Březina wrote:
> Hi devs,
>
> I'm thinking about ways to implement SSSD KCM notification that
> something has changed (i.e. user called kinit/kdestroy) [1]. The main
> use case is to notify Gnome Online Accounts (which is a daemon running
> under logged-in user) when something has changed and it is already a
> D-Bus service.
>
> The basic idea is that we would use D-Bus signals that would be emitted
> by SSSD KCM responder (sssd_kcm process). Signals are broadcasted
> messages that are delivered to client that chose to listen to them.
>
> The problem is that we
> 1) can't connect to specific user's session bus because KCM runs as
> root/sssd and connecting to other user's bus is not allowed
> 2) can't specify which user is allowed to get the signal
Can you explain what this means?
> 3) therefore we can't send the signal only to specific user
Why not?
We definitely should be able to know what user is listening on the
other side of a bus, so we could simply only send back info related to
that same user? Or are we blinded to which user is interacting with us?
> So the solution is that KCM connects to system bus and sends
> org.sssd.kcm.Changed(uid) signal where uid is uid of the user which
> ccache has changed so the receiver can know which user is affected. This
> signal is broadcasted to everyone who listens to it.
This means users can monitor each other, sounds bad.
> It is perfectly usable, however the question is whether we can broadcast
> this information (that user A run kinit/kdestroy/other modification of
> ccache) or it is a security leak that we must avoid and we should seek
> other solution.
Looks quite bad, why do we need to broadcast to everyone?
Isn't there an interface where a specific user can initiate a listening
channel and we send back only info related to that user?
> I asked this secalert and they reply that there is no security concern
> "but":
>
> > After looking at this issue, honestly I dont see an attack vector here, but
> > i am afraid something like this could be used with some other security flaw
> > to maybe gain privesc? For example a flaw which is some component which can
> > be triggered only when kinit is run? where precise timing is required.
> >
> > So in conclusion if there is another "better" solution than it should be
> > preferred. Or in worse case atleast have an option to disable this somehow
> > via some config, so that such situations can be avoided.
>
> I don't think a precise timing is necessary and we can send the signal
> few miliseconds or a second later. That should eliminate this concern (I
> asked this, waiting for an answer).
It's more of a privacy reason to me, if we can find other ways that do
not broadcast this to everyone I think it would be better.
> I can think of two more solutions currently:
>
> 1) Have client connect to KCM socket and await signal there. This
> however would mean that connection between client and KCM need to be
> always established and KCM responder would be running all the time
> (currently it is only short-lived socket activated process).
Is this (shortlivedness) why we can't use a listener ?
> 2) Create a temporary file in a directory owned by user. User can then
> setup inotify watch to the file and sssd would write to the file on
> changes. Since it is in directory owned by user, other users would not
> be able to setup the watch.
But how will the daemon be able to do this?
At the very least the file would need to be in /run/user because home
directories could be on NFS where root can't write, and besides this is
really temporary state and has no business in home directories.
> Note that it is possile to setup inotify watch on FILE ccache (keeping
> distro settings out of the question the default ccache is
> FILE:/tmp/krb5cc_%{uid} as per krb5.conf manpage) so perhaps we really
> don't have to care about broadcasting this information.
That is a good point, I still dislike actively broadcasting around I
wonder if it is possible to just reconnect to the system bus and learn
who is listening and just target those listeners as appropriate.
Is the system bus stateful? Do clients have to reconnect whenever a
daemon restarts?
> Thanks,
> Pavel.
>
> [1] https://pagure.io/SSSD/sssd/issue/3568
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
[SSSD] [sssd PR#990][comment] ci: keep system list outside repository
URL: https://github.com/SSSD/sssd/pull/990 Title: #990: ci: keep system list outside repository pbrezina commented: """ I will provide more documentation in-code once tests will finish and push new version. """ See the full comment at https://github.com/SSSD/sssd/pull/990#issuecomment-589037505 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
[SSSD] [sssd PR#990][synchronized] ci: keep system list outside repository
URL: https://github.com/SSSD/sssd/pull/990
Author: pbrezina
Title: #990: ci: keep system list outside repository
Action: synchronized
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/990/head:pr990
git checkout pr990
From b38ea803ea903783cfe097f62d0e9840b9dfe598 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pavel=20B=C5=99ezina?=
Date: Thu, 20 Feb 2020 13:22:09 +0100
Subject: [PATCH] ci: keep system list outside repository
This way we do not need to push new commit to repository every time
when we change the list of distribution we test on and changes
will be immediately picked up by opened pull request without the
need to rebase them.
It will also help us to temporarily disable particular distribution
when there are errors that we can not fix (e.g. current rawhide issue)
so we can still have all green results.
---
Jenkinsfile | 40 +---
1 file changed, 21 insertions(+), 19 deletions(-)
diff --git a/Jenkinsfile b/Jenkinsfile
index 403f9413c7..042bf2663b 100644
--- a/Jenkinsfile
+++ b/Jenkinsfile
@@ -1,20 +1,6 @@
import hudson.AbortException
import org.jenkinsci.plugins.workflow.steps.FlowInterruptedException
-/* Tests will be run on these systems.
- * To add a new sytem simple extend this list.
- */
-def systems = [
- 'fedora28',
- 'fedora29',
- 'fedora30',
- 'fedora31',
- 'fedora-rawhide',
- 'rhel7',
- 'debian10',
- 'centos7'
-]
-
/* Send notifications to Github.
* If it is an on-demand run then no notifications are sent.
*/
@@ -259,6 +245,7 @@ class OnDemandTest extends Test {
}
}
+def systems = []
def on_demand = params.ON_DEMAND ? true : false
def notification = new Notification(
this, 'sssd-ci',
@@ -267,13 +254,28 @@ def notification = new Notification(
on_demand
)
-if (params.SYSTEMS) {
- if (params.SYSTEMS != 'all') {
-systems = params.SYSTEMS.split()
+try {
+ stage('Get system list') {
+node('master') {
+ if (params.SYSTEMS && params.SYSTEMS != 'all') {
+systems = params.SYSTEMS.split()
+ } else {
+def branch = env.CHANGE_TARGET ? env.CHANGE_TARGET : 'master'
+def config = "systems-${branch}"
+echo "Using configuration: ${config}"
+configFileProvider([
+ configFile(fileId: config, variable: 'SYSTEMS')
+]) {
+ def contents = readFile "${env.SYSTEMS}"
+ systems = contents.split()
+}
+ }
+
+ echo 'Test will be done on following systems:'
+ echo systems.join(', ')
+}
}
-}
-try {
/* Setup nice build description so pull request are easy to find. */
stage('Setup description') {
node('master') {
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
[SSSD] [sssd PR#990][opened] ci: keep system list outside repository
URL: https://github.com/SSSD/sssd/pull/990
Author: pbrezina
Title: #990: ci: keep system list outside repository
Action: opened
PR body:
"""
This way we do not need to push new commit to repository every time
when we change the list of distribution we test on and changes
will be immediately picked up by opened pull request without the
need to rebase them.
It will also help us to temporarily disable particular distribution
when there are errors that we can not fix (e.g. current rawhide issue)
so we can still have all green results.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/990/head:pr990
git checkout pr990
From 01e58995c252faad461119665df3005ed1acba6d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pavel=20B=C5=99ezina?=
Date: Thu, 20 Feb 2020 13:22:09 +0100
Subject: [PATCH] ci: keep system list outside repository
This way we do not need to push new commit to repository every time
when we change the list of distribution we test on and changes
will be immediately picked up by opened pull request without the
need to rebase them.
It will also help us to temporarily disable particular distribution
when there are errors that we can not fix (e.g. current rawhide issue)
so we can still have all green results.
---
Jenkinsfile | 40 +---
1 file changed, 21 insertions(+), 19 deletions(-)
diff --git a/Jenkinsfile b/Jenkinsfile
index 403f9413c7..29b4b365ae 100644
--- a/Jenkinsfile
+++ b/Jenkinsfile
@@ -1,20 +1,6 @@
import hudson.AbortException
import org.jenkinsci.plugins.workflow.steps.FlowInterruptedException
-/* Tests will be run on these systems.
- * To add a new sytem simple extend this list.
- */
-def systems = [
- 'fedora28',
- 'fedora29',
- 'fedora30',
- 'fedora31',
- 'fedora-rawhide',
- 'rhel7',
- 'debian10',
- 'centos7'
-]
-
/* Send notifications to Github.
* If it is an on-demand run then no notifications are sent.
*/
@@ -259,6 +245,7 @@ class OnDemandTest extends Test {
}
}
+def systems = []
def on_demand = params.ON_DEMAND ? true : false
def notification = new Notification(
this, 'sssd-ci',
@@ -267,13 +254,28 @@ def notification = new Notification(
on_demand
)
-if (params.SYSTEMS) {
- if (params.SYSTEMS != 'all') {
-systems = params.SYSTEMS.split()
+try {
+ stage('Get system list') {
+node('master') {
+ if (params.SYSTEMS && params.SYSTEMS != 'all') {
+systems = params.SYSTEMS.split()
+ } else {
+def branch = env.CHANGE_TARGET ? env.CHANGE_TARGET : 'master'
+def config = "systems-${branch}"
+echo "Using configuration: ${config}"
+configFileProvider([
+ configFile(fileId: config, variable: 'SYSTEMS')
+]) {
+ def contents = readFile "${env.SYSTEMS}"
+ systems = contents.split()
+}
+ }
+
+ echo 'Test will be done on following systems:'
+ echo systems.join(', ')
+}
}
-}
-try {
/* Setup nice build description so pull request are easy to find. */
stage('Setup description') {
node('master') {
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
[SSSD] [sssd PR#987][comment] SSSDConfig: New SSSDOptions class
URL: https://github.com/SSSD/sssd/pull/987 Title: #987: SSSDConfig: New SSSDOptions class alexal commented: """ @pbrezina, I did that because there was the following TODO: > # TODO: This needs to be made external """ See the full comment at https://github.com/SSSD/sssd/pull/987#issuecomment-588977568 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
[SSSD] [sssd PR#989][opened] config: allowed auto_private_groups in child domains
URL: https://github.com/SSSD/sssd/pull/989 Author: ikerexxe Title: #989: config: allowed auto_private_groups in child domains Action: opened PR body: """ sssctl config-check failed if auto_private_groups was enabled/disabled in child domains Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1791892 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/989/head:pr989 git checkout pr989 From c0abebead2990c26cea685bbd8c8ad79139881eb Mon Sep 17 00:00:00 2001 From: ikerexxe Date: Thu, 20 Feb 2020 12:20:33 +0100 Subject: [PATCH] config: allowed auto_private_groups in child domains sssctl config-check failed if auto_private_groups was enabled/disabled in child domains Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1791892 --- src/config/cfg_rules.ini | 1 + 1 file changed, 1 insertion(+) diff --git a/src/config/cfg_rules.ini b/src/config/cfg_rules.ini index 054d74be5a..24ae794c30 100644 --- a/src/config/cfg_rules.ini +++ b/src/config/cfg_rules.ini @@ -771,6 +771,7 @@ option = ad_server option = ad_backup_server option = ad_site option = use_fully_qualified_names +option = auto_private_groups [rule/sssd_checks] validator = sssd_checks ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
[SSSD] KCM notifications
Hi devs,
I'm thinking about ways to implement SSSD KCM notification that
something has changed (i.e. user called kinit/kdestroy) [1]. The main
use case is to notify Gnome Online Accounts (which is a daemon running
under logged-in user) when something has changed and it is already a
D-Bus service.
The basic idea is that we would use D-Bus signals that would be emitted
by SSSD KCM responder (sssd_kcm process). Signals are broadcasted
messages that are delivered to client that chose to listen to them.
The problem is that we
1) can't connect to specific user's session bus because KCM runs as
root/sssd and connecting to other user's bus is not allowed
2) can't specify which user is allowed to get the signal
3) therefore we can't send the signal only to specific user
So the solution is that KCM connects to system bus and sends
org.sssd.kcm.Changed(uid) signal where uid is uid of the user which
ccache has changed so the receiver can know which user is affected. This
signal is broadcasted to everyone who listens to it.
It is perfectly usable, however the question is whether we can broadcast
this information (that user A run kinit/kdestroy/other modification of
ccache) or it is a security leak that we must avoid and we should seek
other solution.
I asked this secalert and they reply that there is no security concern
"but":
After looking at this issue, honestly I dont see an attack vector here, but i
am afraid something like this could be used with some other security flaw to
maybe gain privesc? For example a flaw which is some component which can be
triggered only when kinit is run? where precise timing is required.
So in conclusion if there is another "better" solution than it should be
preferred. Or in worse case atleast have an option to disable this somehow via some
config, so that such situations can be avoided.
I don't think a precise timing is necessary and we can send the signal
few miliseconds or a second later. That should eliminate this concern (I
asked this, waiting for an answer).
I can think of two more solutions currently:
1) Have client connect to KCM socket and await signal there. This
however would mean that connection between client and KCM need to be
always established and KCM responder would be running all the time
(currently it is only short-lived socket activated process).
2) Create a temporary file in a directory owned by user. User can then
setup inotify watch to the file and sssd would write to the file on
changes. Since it is in directory owned by user, other users would not
be able to setup the watch.
Note that it is possile to setup inotify watch on FILE ccache (keeping
distro settings out of the question the default ccache is
FILE:/tmp/krb5cc_%{uid} as per krb5.conf manpage) so perhaps we really
don't have to care about broadcasting this information.
Thanks,
Pavel.
[1] https://pagure.io/SSSD/sssd/issue/3568
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
[SSSD] [sssd PR#983][closed] GPO: Duplicated error message for unreadable GPO
URL: https://github.com/SSSD/sssd/pull/983 Author: elkoniu Title: #983: GPO: Duplicated error message for unreadable GPO Action: closed To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/983/head:pr983 git checkout pr983 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
[SSSD] [sssd PR#983][-Ready to push] GPO: Duplicated error message for unreadable GPO
URL: https://github.com/SSSD/sssd/pull/983 Title: #983: GPO: Duplicated error message for unreadable GPO Label: -Ready to push ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
[SSSD] [sssd PR#983][-Accepted] GPO: Duplicated error message for unreadable GPO
URL: https://github.com/SSSD/sssd/pull/983 Title: #983: GPO: Duplicated error message for unreadable GPO Label: -Accepted ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
[SSSD] [sssd PR#983][+Pushed] GPO: Duplicated error message for unreadable GPO
URL: https://github.com/SSSD/sssd/pull/983 Title: #983: GPO: Duplicated error message for unreadable GPO Label: +Pushed ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
[SSSD] [sssd PR#983][comment] GPO: Duplicated error message for unreadable GPO
URL: https://github.com/SSSD/sssd/pull/983 Title: #983: GPO: Duplicated error message for unreadable GPO pbrezina commented: """ * `master` * 9188aa17d9c4dfec1d5744981ea8855465965808 - GPO: Duplicated error message for unreadable GPO """ See the full comment at https://github.com/SSSD/sssd/pull/983#issuecomment-588871384 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
[SSSD] [sssd PR#984][+Pushed] 1.16: memberof: keep memberOf attribute for nested member
URL: https://github.com/SSSD/sssd/pull/984 Title: #984: 1.16: memberof: keep memberOf attribute for nested member Label: +Pushed ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
[SSSD] [sssd PR#984][-Ready to push] 1.16: memberof: keep memberOf attribute for nested member
URL: https://github.com/SSSD/sssd/pull/984 Title: #984: 1.16: memberof: keep memberOf attribute for nested member Label: -Ready to push ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
[SSSD] [sssd PR#984][-Accepted] 1.16: memberof: keep memberOf attribute for nested member
URL: https://github.com/SSSD/sssd/pull/984 Title: #984: 1.16: memberof: keep memberOf attribute for nested member Label: -Accepted ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
[SSSD] [sssd PR#984][closed] 1.16: memberof: keep memberOf attribute for nested member
URL: https://github.com/SSSD/sssd/pull/984 Author: pbrezina Title: #984: 1.16: memberof: keep memberOf attribute for nested member Action: closed To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/984/head:pr984 git checkout pr984 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
[SSSD] [sssd PR#984][comment] 1.16: memberof: keep memberOf attribute for nested member
URL: https://github.com/SSSD/sssd/pull/984 Title: #984: 1.16: memberof: keep memberOf attribute for nested member pbrezina commented: """ * `sssd-1-16` * 9a7c044dcd17b23127ddda25ff9cddc9c67fe4ca - memberof: keep memberOf attribute for nested member """ See the full comment at https://github.com/SSSD/sssd/pull/984#issuecomment-588870106 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
[SSSD] [sssd PR#987][comment] SSSDConfig: New SSSDOptions class
URL: https://github.com/SSSD/sssd/pull/987 Title: #987: SSSDConfig: New SSSDOptions class pbrezina commented: """ Sorry, not yet. Why did you implement this change? """ See the full comment at https://github.com/SSSD/sssd/pull/987#issuecomment-588868475 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
[SSSD] [sssd PR#987][+Waiting for review] SSSDConfig: New SSSDOptions class
URL: https://github.com/SSSD/sssd/pull/987 Title: #987: SSSDConfig: New SSSDOptions class Label: +Waiting for review ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
