[SSSD] [sssd PR#69][comment] krb5: Use command line arguments instead env vars for krb5_child
URL: https://github.com/SSSD/sssd/pull/69 Title: #69: krb5: Use command line arguments instead env vars for krb5_child sumit-bose commented: """ Thank you for the rigid testing, it was a typo in the command line option names. To avoid this I switched to #defines for all option name usage. """ See the full comment at https://github.com/SSSD/sssd/pull/69#issuecomment-261061796 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#69][-Changes requested] krb5: Use command line arguments instead env vars for krb5_child
URL: https://github.com/SSSD/sssd/pull/69 Title: #69: krb5: Use command line arguments instead env vars for krb5_child Label: -Changes requested ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#69][synchronized] krb5: Use command line arguments instead env vars for krb5_child
URL: https://github.com/SSSD/sssd/pull/69
Author: sumit-bose
Title: #69: krb5: Use command line arguments instead env vars for krb5_child
Action: synchronized
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/69/head:pr69
git checkout pr69
From 67d1e9ade4149145a7b0f01e3562a81fea285a07 Mon Sep 17 00:00:00 2001
From: Sumit Bose
Date: Fri, 28 Oct 2016 21:29:45 +0200
Subject: [PATCH 1/3] krb5: Use command line arguments instead env vars for
krb5_child
Resolves https://fedorahosted.org/sssd/ticket/697
---
src/providers/krb5/krb5_auth.h | 9 +++
src/providers/krb5/krb5_child.c | 129 ++
src/providers/krb5/krb5_child_handler.c | 134 ++--
src/providers/krb5/krb5_common.c| 91 +-
src/providers/krb5/krb5_common.h| 25 +++---
src/providers/krb5/krb5_init_shared.c | 5 +-
6 files changed, 268 insertions(+), 125 deletions(-)
diff --git a/src/providers/krb5/krb5_auth.h b/src/providers/krb5/krb5_auth.h
index 11bb595..75ad916 100644
--- a/src/providers/krb5/krb5_auth.h
+++ b/src/providers/krb5/krb5_auth.h
@@ -38,6 +38,15 @@
#define ILLEGAL_PATH_PATTERN "//|/\\./|/\\.\\./"
+#define CHILD_OPT_FAST_CCACHE_UID "fast-ccache-uid"
+#define CHILD_OPT_FAST_CCACHE_GID "fast-ccache-gid"
+#define CHILD_OPT_REALM "realm"
+#define CHILD_OPT_LIFETIME "lifetime"
+#define CHILD_OPT_RENEWABLE_LIFETIME "renewable-lifetime"
+#define CHILD_OPT_USE_FAST "use-fast"
+#define CHILD_OPT_FAST_PRINCIPAL "fast-principal"
+#define CHILD_OPT_CANONICALIZE "canonicalize"
+
struct krb5child_req {
struct pam_data *pd;
struct krb5_ctx *krb5_ctx;
diff --git a/src/providers/krb5/krb5_child.c b/src/providers/krb5/krb5_child.c
index df94bc4..61a77db 100644
--- a/src/providers/krb5/krb5_child.c
+++ b/src/providers/krb5/krb5_child.c
@@ -48,6 +48,15 @@ enum k5c_fast_opt {
K5C_FAST_DEMAND,
};
+struct cli_opts {
+char *realm;
+char *lifetime;
+char *rtime;
+char *use_fast_str;
+char *fast_principal;
+bool canonicalize;
+};
+
struct krb5_req {
krb5_context ctx;
krb5_principal princ;
@@ -81,73 +90,68 @@ struct krb5_req {
uid_t fast_uid;
gid_t fast_gid;
+
+struct cli_opts *cli_opts;
};
static krb5_context krb5_error_ctx;
#define KRB5_CHILD_DEBUG(level, error) KRB5_DEBUG(level, krb5_error_ctx, error)
-static krb5_error_code set_lifetime_options(krb5_get_init_creds_opt *options)
+static krb5_error_code set_lifetime_options(struct cli_opts *cli_opts,
+krb5_get_init_creds_opt *options)
{
-char *lifetime_str;
krb5_error_code kerr;
krb5_deltat lifetime;
-lifetime_str = getenv(SSSD_KRB5_RENEWABLE_LIFETIME);
-if (lifetime_str == NULL) {
-DEBUG(SSSDBG_CONF_SETTINGS, "Cannot read [%s] from environment.\n",
- SSSD_KRB5_RENEWABLE_LIFETIME);
+if (cli_opts->rtime == NULL) {
+DEBUG(SSSDBG_CONF_SETTINGS,
+ "No specific renewable lifetime requested.\n");
/* Unset option flag to make sure defaults from krb5.conf are used. */
options->flags &= ~(KRB5_GET_INIT_CREDS_OPT_RENEW_LIFE);
} else {
-kerr = krb5_string_to_deltat(lifetime_str, &lifetime);
+kerr = krb5_string_to_deltat(cli_opts->rtime, &lifetime);
if (kerr != 0) {
DEBUG(SSSDBG_CRIT_FAILURE,
- "krb5_string_to_deltat failed for [%s].\n",
- lifetime_str);
+ "krb5_string_to_deltat failed for [%s].\n", cli_opts->rtime);
KRB5_CHILD_DEBUG(SSSDBG_CRIT_FAILURE, kerr);
return kerr;
}
-DEBUG(SSSDBG_CONF_SETTINGS, "%s is set to [%s]\n",
- SSSD_KRB5_RENEWABLE_LIFETIME, lifetime_str);
+DEBUG(SSSDBG_CONF_SETTINGS, "Renewable lifetime is set to [%s]\n",
+cli_opts->rtime);
krb5_get_init_creds_opt_set_renew_life(options, lifetime);
}
-lifetime_str = getenv(SSSD_KRB5_LIFETIME);
-if (lifetime_str == NULL) {
-DEBUG(SSSDBG_CONF_SETTINGS, "Cannot read [%s] from environment.\n",
- SSSD_KRB5_LIFETIME);
+if (cli_opts->lifetime == NULL) {
+DEBUG(SSSDBG_CONF_SETTINGS, "No specific lifetime requested.\n");
/* Unset option flag to make sure defaults from krb5.conf are used. */
options->flags &= ~(KRB5_GET_INIT_CREDS_OPT_TKT_LIFE);
} else {
-kerr = krb5_string_to_deltat(lifetime_str, &lifetime);
+kerr = krb5_string_to_deltat(cli_opts->lifetime, &lifetime);
if (kerr != 0) {
DEBUG(SSSDBG_CRIT_FAILURE,
"krb5_string_to_deltat failed for [%s].\n",
- lifetime_str);
+ cli_opts->lifetime);
KRB5_CHILD_DEBUG(SSSDBG_CRIT_FAILURE, kerr);
return kerr;
}
-DEBUG(SSSDBG_CONF_SE
[SSSD] [sssd PR#77][closed] Qualify ghost users with RFC2307bis and ldap_nesting_level=0
URL: https://github.com/SSSD/sssd/pull/77 Author: jhrozek Title: #77: Qualify ghost users with RFC2307bis and ldap_nesting_level=0 Action: closed To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/77/head:pr77 git checkout pr77 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#77][comment] Qualify ghost users with RFC2307bis and ldap_nesting_level=0
URL: https://github.com/SSSD/sssd/pull/77 Title: #77: Qualify ghost users with RFC2307bis and ldap_nesting_level=0 lslebodn commented: """ master: * 65e791f844b4513ca2c3ee23f8cd2979566b3719 * 538a7f1dd8339b90e0cfc64e7919a34d1d5c10d3 sssd-1-14: * a7be684411aff42e03e181dd81de921185e16c34 * e0b544e6f664c2ce5ddd8df866d996607ce488cc """ See the full comment at https://github.com/SSSD/sssd/pull/77#issuecomment-260959317 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#77][comment] Qualify ghost users with RFC2307bis and ldap_nesting_level=0
URL: https://github.com/SSSD/sssd/pull/77
Title: #77: Qualify ghost users with RFC2307bis and ldap_nesting_level=0
lslebodn commented:
"""
There are few pep8 issues
```
diff --git a/src/tests/intg/test_ldap.py b/src/tests/intg/test_ldap.py
index 667ae27..bf25d95 100644
--- a/src/tests/intg/test_ldap.py
+++ b/src/tests/intg/test_ldap.py
@@ -952,6 +952,7 @@ def test_remove_user_from_nested_group(ldap_conn,
ent.assert_group_by_name("group3",
dict(mem=ent.contains_only()))
+
def zero_nesting_sssd_conf(ldap_conn, schema):
"""Format an SSSD configuration with group nesting disabled"""
return \
@@ -961,6 +962,7 @@ def zero_nesting_sssd_conf(ldap_conn, schema):
ldap_group_nesting_level= 0
""").format(INTERACTIVE_TIMEOUT)
+
@pytest.fixture
def rfc2307bis_no_nesting(request, ldap_conn):
ent_list = ldap_ent.List(ldap_conn.ds_inst.base_dn)
@@ -974,6 +976,7 @@ def rfc2307bis_no_nesting(request, ldap_conn):
create_sssd_fixture(request)
return None
+
def test_zero_nesting_level(ldap_conn, rfc2307bis_no_nesting):
ent.assert_group_by_name("group1",
dict(mem=ent.contains_only("user1")))
```
I will fix them before pushing patches.
Thank you very much for integration test.
BTW downstream tests did not find any regressions.
ACK
LS
"""
See the full comment at
https://github.com/SSSD/sssd/pull/77#issuecomment-260951073
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#69][+Changes requested] krb5: Use command line arguments instead env vars for krb5_child
URL: https://github.com/SSSD/sssd/pull/69 Title: #69: krb5: Use command line arguments instead env vars for krb5_child Label: +Changes requested ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#69][comment] krb5: Use command line arguments instead env vars for krb5_child
URL: https://github.com/SSSD/sssd/pull/69 Title: #69: krb5: Use command line arguments instead env vars for krb5_child lslebodn commented: """ On (11/11/16 03:13), sumit-bose wrote: >Sorry, this issue was introduced by a assume simple last minute change which I >didn't test properly. I couldn't decide if I want to keep the options in the >global krb5_ctx since the currently do not change or if they will always be >generated on the fly. I finally picked the latter to avoid issues in future >with options changing per request but didn't do the change properly. > I ran some downstream tests and there are failures with authentication for krb5-fast-principal related tests sssd.conf lokks like: ``` [domain/LDAP-KRB5] debug_level=0xFFF0 id_provider = ldap ldap_uri = ldap://$SERVER ldap_search_base = dc=example,dc=com auth_provider = krb5 krb5_server = $SERVER krb5_realm = EXAMPLE.COM krb5_use_fast = demand krb5_fast_principal = host/$CLIENT ``` ``` [domain/LDAP-KRB5] debug_level=0xFFF0 id_provider = ldap ldap_uri = ldap://$SERVER ldap_search_base = dc=example,dc=com auth_provider = krb5 krb5_server = $SERVER krb5_realm = EXAMPLE.COM krb5_use_fast = demand krb5_fast_principal = host/$CLIENT krb5_validate = true ``` and maybe more issues later :-) LS """ See the full comment at https://github.com/SSSD/sssd/pull/69#issuecomment-260936892 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: [RFC] Socket-activate responders
On Wed, Nov 16, 2016 at 11:46:03AM +0100, Fabiano Fidêncio wrote: > On Wed, Nov 16, 2016 at 11:20 AM, Jakub Hrozek wrote: > > On Wed, Nov 16, 2016 at 10:03:36AM +0100, Fabiano Fidêncio wrote: > >> People, > >> > >> I've spent some time looking at the code and trying to understand what > >> are the needed changes in order to have this task done. I'll start by > >> writing down how things are working nowadays, what we want to achieve, > >> what are the parts that will need to be touched and what are the steps > >> that I'm going to take. Please, keep in mind that I may have a wrong > >> (or at least not so clear) understanding of all these points that I'm > >> about to explain and in case I made some mistake feel free to jump in > >> and correct me. Also, whatever we sum up from this email will be > >> written down in our DesignFeatures page. Let's start ... > >> > >> How things work nowadays: > >> > >> > >> Nowadays all the services are started and taken care by the monitor. > >> It basically means that the monitor checks which are the services > >> listed to be started, starts those and registers them in order to > >> relay them signals coming from our tools. Here I'm not sure whether > >> the monitor relays signals from something else but the tools, but > >> doesn't seem to be case (and please, correct me in case I'm wrong). > > > > Monitor also relays: > > - signals that the administrator sends manually (see man sssd(8) and > > search for USR1/USR2/HUP) > > This actually affects the responders, right? > > > - notifications that /etc/resolv.conf had changed and the domains > > should reset their offline status > > - notifications that networking on the machine had changed (received > > via the netlink socket) and the domains should reset their offline > > status > > These don't as far as I understand. > > > > > These mostly (except for clearing the memory cache of NSS responder and > > rotating the logs) concern the providers which we won't be changing now. > > > > And actually I wouldn't see too much harm with moving the resolv.conf > > monitoring and netlink monitoring to back ends themselves..both 'just' > > mean an open fd and the number of sssd_be processes running is usually > > small. > > Right, I like the suggestion but I'd like to keep this out of the > scope for this task right now. > > > > >> > >> What we want to achieve: > >> - > >> > >> While my personal desire is to start slowly killing the monitor, > >> that's not going to be case right now. > > > > Well, we can incrementally downsize the monitor.. > > > >> We don't want to do any change in the code that wouldn't also > >> contemplate platforms where systemd is not available. > > > > Yes, but perhaps we can move the non-systemd code to a separate module > > to avoid a lot of code in the monitor being #ifdef-ed out. (I don't know > > if this will actually be the case in the end) > > That's a good idea. > I'll go pretty much if-def'ing the code and in the end split this part > into a separate module in case it makes sense. > > > > >> That being said, > >> let's move to the important part ... > >> > >> Here what we want to achieve is to have all responders (at least for > >> now, yes, just the responders) socket-activatable as some of them > >> don't actually have to be running all the time (that's the case, for > >> example, of the ssh, sudo and ifp responders). We also have to keep > >> into consideration that _any_ change in behaviour should _not_ happen, > >> which means that we still have to honor our compromise with sssd.conf > >> and still make the responders manually activated there to start and be > >> running from the moment sssd is running (as we do nowadays). > > > > Right, this is a possibility. I think we can use the "services" line to > > configure how the responders are started. If any service was explicitly > > listed in "services", then it would be also explicitly started by the > > monitor just as it is now. > > Right. > > > > > I think we also want to add an idle timeout to the services and the services > > that are started explicitly would just have an infinite idle timeout.. > > Why? If the services are started explicitly we can just use the same > logic used nowadays. Yes. > So, I have the feeling that no changes would be needed at all in this case. I thought we wanted to add an idle timeout to services that are only seldom needed like secrets or sudo to avoid running them all the time.. This could be a tevent timer that is cancelled and restarted when a new client connects and its period could be set from the command line or from a config parameter. > > > > > Other systemd services that correspond to a responder might be disabled > > by default and the admin can just activate them to allow them to be > > started on demand (that's already the case with sssd-secrets, right?) > > Yes, you're
[SSSD] Re: [RFC] Socket-activate responders
On Wed, Nov 16, 2016 at 11:20 AM, Jakub Hrozek wrote: > On Wed, Nov 16, 2016 at 10:03:36AM +0100, Fabiano Fidêncio wrote: >> People, >> >> I've spent some time looking at the code and trying to understand what >> are the needed changes in order to have this task done. I'll start by >> writing down how things are working nowadays, what we want to achieve, >> what are the parts that will need to be touched and what are the steps >> that I'm going to take. Please, keep in mind that I may have a wrong >> (or at least not so clear) understanding of all these points that I'm >> about to explain and in case I made some mistake feel free to jump in >> and correct me. Also, whatever we sum up from this email will be >> written down in our DesignFeatures page. Let's start ... >> >> How things work nowadays: >> >> >> Nowadays all the services are started and taken care by the monitor. >> It basically means that the monitor checks which are the services >> listed to be started, starts those and registers them in order to >> relay them signals coming from our tools. Here I'm not sure whether >> the monitor relays signals from something else but the tools, but >> doesn't seem to be case (and please, correct me in case I'm wrong). > > Monitor also relays: > - signals that the administrator sends manually (see man sssd(8) and > search for USR1/USR2/HUP) This actually affects the responders, right? > - notifications that /etc/resolv.conf had changed and the domains > should reset their offline status > - notifications that networking on the machine had changed (received > via the netlink socket) and the domains should reset their offline > status These don't as far as I understand. > > These mostly (except for clearing the memory cache of NSS responder and > rotating the logs) concern the providers which we won't be changing now. > > And actually I wouldn't see too much harm with moving the resolv.conf > monitoring and netlink monitoring to back ends themselves..both 'just' > mean an open fd and the number of sssd_be processes running is usually small. Right, I like the suggestion but I'd like to keep this out of the scope for this task right now. > >> >> What we want to achieve: >> - >> >> While my personal desire is to start slowly killing the monitor, >> that's not going to be case right now. > > Well, we can incrementally downsize the monitor.. > >> We don't want to do any change in the code that wouldn't also >> contemplate platforms where systemd is not available. > > Yes, but perhaps we can move the non-systemd code to a separate module > to avoid a lot of code in the monitor being #ifdef-ed out. (I don't know > if this will actually be the case in the end) That's a good idea. I'll go pretty much if-def'ing the code and in the end split this part into a separate module in case it makes sense. > >> That being said, >> let's move to the important part ... >> >> Here what we want to achieve is to have all responders (at least for >> now, yes, just the responders) socket-activatable as some of them >> don't actually have to be running all the time (that's the case, for >> example, of the ssh, sudo and ifp responders). We also have to keep >> into consideration that _any_ change in behaviour should _not_ happen, >> which means that we still have to honor our compromise with sssd.conf >> and still make the responders manually activated there to start and be >> running from the moment sssd is running (as we do nowadays). > > Right, this is a possibility. I think we can use the "services" line to > configure how the responders are started. If any service was explicitly > listed in "services", then it would be also explicitly started by the > monitor just as it is now. Right. > > I think we also want to add an idle timeout to the services and the services > that are started explicitly would just have an infinite idle timeout.. Why? If the services are started explicitly we can just use the same logic used nowadays. So, I have the feeling that no changes would be needed at all in this case. > > Other systemd services that correspond to a responder might be disabled > by default and the admin can just activate them to allow them to be > started on demand (that's already the case with sssd-secrets, right?) Yes, you're right. > > But this could also be just a middle step..in future, since the responder > Requires sssd.service, I think we could just let the monitor > socket-activate the responder as well /after/ starting the back ends. Or > is there another reason for starting some services explicitly except for > maintaining the status quo and being a bit more on the safe side? The reason for me would be, only, to be a bit more on the safe side. > >> >> How we plan to achieve our goal: >> --- >> >> Some parts I have a pretty clear idea on what to do, some ot
[SSSD] [sssd PR#80][opened] SYSDB: Sudorule without a sudoUser returns EINVAL
URL: https://github.com/SSSD/sssd/pull/80
Author: celestian
Title: #80: SYSDB: Sudorule without a sudoUser returns EINVAL
Action: opened
PR body:
"""
This patch solved a regression caused by the recent patches
to lowercase sudoUser -- in case sudoUser is missing completely,
we abort the processing of this rule and all others.
With this patch, we return EINVAL and gracefully skip
the malgormed rule instead.
Resolves:
https://fedorahosted.org/sssd/ticket/3241
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/80/head:pr80
git checkout pr80
From 8877575954842bb2dfcf545b79a3db3ee06521a4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20=C4=8Cech?=
Date: Wed, 16 Nov 2016 10:09:18 +0100
Subject: [PATCH] SYSDB: Sudorule without a sudoUser returns EINVAL
This patch solved a regression caused by the recent patches
to lowercase sudoUser -- in case sudoUser is missing completely,
we abort the processing of this rule and all others.
With this patch, we return EINVAL and gracefully skip
the malgormed rule instead.
Resolves:
https://fedorahosted.org/sssd/ticket/3241
---
src/db/sysdb_sudo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/db/sysdb_sudo.c b/src/db/sysdb_sudo.c
index 4bd93ff..0a59e89 100644
--- a/src/db/sysdb_sudo.c
+++ b/src/db/sysdb_sudo.c
@@ -874,6 +874,7 @@ static errno_t sysdb_sudo_add_lowered_users(struct sss_domain_info *domain,
if (ret != EOK) {
DEBUG(SSSDBG_OP_FAILURE, "Unable to get %s attribute [%d]: %s\n",
SYSDB_SUDO_CACHE_AT_USER, ret, strerror(ret));
+ret = EINVAL;
goto done;
}
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: [RFC] Socket-activate responders
On Wed, Nov 16, 2016 at 10:03:36AM +0100, Fabiano Fidêncio wrote: > People, > > I've spent some time looking at the code and trying to understand what > are the needed changes in order to have this task done. I'll start by > writing down how things are working nowadays, what we want to achieve, > what are the parts that will need to be touched and what are the steps > that I'm going to take. Please, keep in mind that I may have a wrong > (or at least not so clear) understanding of all these points that I'm > about to explain and in case I made some mistake feel free to jump in > and correct me. Also, whatever we sum up from this email will be > written down in our DesignFeatures page. Let's start ... > > How things work nowadays: > > > Nowadays all the services are started and taken care by the monitor. > It basically means that the monitor checks which are the services > listed to be started, starts those and registers them in order to > relay them signals coming from our tools. Here I'm not sure whether > the monitor relays signals from something else but the tools, but > doesn't seem to be case (and please, correct me in case I'm wrong). Monitor also relays: - signals that the administrator sends manually (see man sssd(8) and search for USR1/USR2/HUP) - notifications that /etc/resolv.conf had changed and the domains should reset their offline status - notifications that networking on the machine had changed (received via the netlink socket) and the domains should reset their offline status These mostly (except for clearing the memory cache of NSS responder and rotating the logs) concern the providers which we won't be changing now. And actually I wouldn't see too much harm with moving the resolv.conf monitoring and netlink monitoring to back ends themselves..both 'just' mean an open fd and the number of sssd_be processes running is usually small. > > What we want to achieve: > - > > While my personal desire is to start slowly killing the monitor, > that's not going to be case right now. Well, we can incrementally downsize the monitor.. > We don't want to do any change in the code that wouldn't also > contemplate platforms where systemd is not available. Yes, but perhaps we can move the non-systemd code to a separate module to avoid a lot of code in the monitor being #ifdef-ed out. (I don't know if this will actually be the case in the end) > That being said, > let's move to the important part ... > > Here what we want to achieve is to have all responders (at least for > now, yes, just the responders) socket-activatable as some of them > don't actually have to be running all the time (that's the case, for > example, of the ssh, sudo and ifp responders). We also have to keep > into consideration that _any_ change in behaviour should _not_ happen, > which means that we still have to honor our compromise with sssd.conf > and still make the responders manually activated there to start and be > running from the moment sssd is running (as we do nowadays). Right, this is a possibility. I think we can use the "services" line to configure how the responders are started. If any service was explicitly listed in "services", then it would be also explicitly started by the monitor just as it is now. I think we also want to add an idle timeout to the services and the services that are started explicitly would just have an infinite idle timeout.. Other systemd services that correspond to a responder might be disabled by default and the admin can just activate them to allow them to be started on demand (that's already the case with sssd-secrets, right?) But this could also be just a middle step..in future, since the responder Requires sssd.service, I think we could just let the monitor socket-activate the responder as well /after/ starting the back ends. Or is there another reason for starting some services explicitly except for maintaining the status quo and being a bit more on the safe side? > > How we plan to achieve our goal: > --- > > Some parts I have a pretty clear idea on what to do, some others not > that much. The basic idea is to take as much advantage of systemd > machinery as we can and "remove" as much duties as possible from the > monitor. Let's go through this by parts ... > > - Starting the service: the idea is to have a systemd unit for each of > the responders. Whether these units will be automatically generated by > us is a detail that doesn't worth attention right now. Let's take a > look on what the unit will look like: > > [Unit] > Description=SSSD @responder@ service provider > > [Install] > Also=sssd-@responder@.socket > > [Service] > ExecStart==@libexecdir@/sssd/sssd_@responder@ --uid 0 --gid 0 --debug-to-files I wonder if the service could start as root and then read the 'user' from confdb to learn if it's suppose
[SSSD] [RFC] Socket-activate responders
People, I've spent some time looking at the code and trying to understand what are the needed changes in order to have this task done. I'll start by writing down how things are working nowadays, what we want to achieve, what are the parts that will need to be touched and what are the steps that I'm going to take. Please, keep in mind that I may have a wrong (or at least not so clear) understanding of all these points that I'm about to explain and in case I made some mistake feel free to jump in and correct me. Also, whatever we sum up from this email will be written down in our DesignFeatures page. Let's start ... How things work nowadays: Nowadays all the services are started and taken care by the monitor. It basically means that the monitor checks which are the services listed to be started, starts those and registers them in order to relay them signals coming from our tools. Here I'm not sure whether the monitor relays signals from something else but the tools, but doesn't seem to be case (and please, correct me in case I'm wrong). What we want to achieve: - While my personal desire is to start slowly killing the monitor, that's not going to be case right now. We don't want to do any change in the code that wouldn't also contemplate platforms where systemd is not available. That being said, let's move to the important part ... Here what we want to achieve is to have all responders (at least for now, yes, just the responders) socket-activatable as some of them don't actually have to be running all the time (that's the case, for example, of the ssh, sudo and ifp responders). We also have to keep into consideration that _any_ change in behaviour should _not_ happen, which means that we still have to honor our compromise with sssd.conf and still make the responders manually activated there to start and be running from the moment sssd is running (as we do nowadays). How we plan to achieve our goal: --- Some parts I have a pretty clear idea on what to do, some others not that much. The basic idea is to take as much advantage of systemd machinery as we can and "remove" as much duties as possible from the monitor. Let's go through this by parts ... - Starting the service: the idea is to have a systemd unit for each of the responders. Whether these units will be automatically generated by us is a detail that doesn't worth attention right now. Let's take a look on what the unit will look like: [Unit] Description=SSSD @responder@ service provider [Install] Also=sssd-@responder@.socket [Service] ExecStart==@libexecdir@/sssd/sssd_@responder@ --uid 0 --gid 0 --debug-to-files Requires=sssd.service PartOf=sssd.service There's two options that deserve some explanation of their usage here: -- "Requires=sssd.service": This option guarantees that sssd will be up when any of the responders are up. Considering that the providers part won't be changed, those will still be initializated synchronously by the monitor and only then notify init that its start up finished, which also mean that the providers' sbus socket will be up. -- "PartOf=sssd.service": This options guarantees that when sssd.service is restarted/stoped all the responders' services will be restarted/stopped accordingly. - Relaying signals: seems the best approach for this in order to replace the registration currently done by the monitor, is to create a named bus for each of the responders so the tools could talk directly to them. By "named bus for each responder" I understand that's a pipe, named sbus-@responder@ that will be used to send the dbus message through it. It would require to adapt the tools code to actually check whether the sbus-@responder@ pipe exists and then send the message, as we won't have a list of the running responders, which may increase the iterations to send a message but I do believe wouldn't hurt us too much due to the small number of responders we have. It will also help tools to be able to set different debug levels for each responder. Seems, at least for me, that doing these steps we are covered with respect to what we have nowadays. Does someone think that we are missing something? What? Please, try to explain in the same way you would explain to a 5 years old kid :-) Coding plan: -- My current plan is to start implementing this whole thing by creating the named bus for each responder and have the communication between the responders and the tools working. Next step will be to actually have the responders started on demand by using socket-activation. And the very last step will be to make sure we can have the responders always running when they're listed in the sssd.conf. I'm not comfortable on giving any estimation about when we will have it done, mainly because I'd like to hear the feedback about this from others in the team. Looking forward for your reading back from you!
[SSSD] [sssd PR#39][comment] RESPONDER: Enable sudoRule in case insen. domains (1.13)
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13) celestian commented: """ I am afraid there is the same issue as in https://fedorahosted.org/sssd/ticket/3241. The patch will be added soon. """ See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-260886546 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#39][+Changes requested] RESPONDER: Enable sudoRule in case insen. domains (1.13)
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13) Label: +Changes requested ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
