[SSSD] Re: Design document - Socket-activatable responders
On 12/01/2016 03:36 PM, Simo Sorce wrote: On Thu, 2016-12-01 at 15:19 +0100, Fabiano Fidêncio wrote: On Thu, Dec 1, 2016 at 2:44 PM, Pavel Březina wrote: On 11/24/2016 02:33 PM, Fabiano Fidêncio wrote: The design page is done [0] and it's based on this discussion [1] we had on this very same mailing list. A pull-request with the implementation is already opened [2]. [0]: https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders [1]: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ [2]: htatps://github.com/SSSD/sssd/pull/84 I think we should also provide 'disabled_services' option, to give admins a way to explicitly disable some responders if the don't want to used them. I have to double check a few things here but, AFAIU, just having the socket disabled (systemctl disable sssd-@responder@.socket) should be enough. I guess I misunderstood what ou mean by "provide 'disabled_services' option", I though you wanted to add that option to sssd.conf Yes, this was my idea. I did not realized that we can just disable the socket trough systemd, this solution is sufficient. This brings up another thing to test though -- what happens if the responder is socket activate and running and than you stop/disable the socket trough systemd? Is SSSD already able to handle it gracefully? ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On Thu, 2016-12-01 at 16:04 +0100, Jakub Hrozek wrote: > On Thu, Dec 01, 2016 at 03:59:37PM +0100, Fabiano Fidêncio wrote: > > On Thu, Dec 1, 2016 at 3:46 PM, Simo Sorce wrote: > > > On Thu, 2016-12-01 at 15:22 +0100, Pavel Březina wrote: > > >> On 12/01/2016 02:56 PM, Simo Sorce wrote: > > >> > On Thu, 2016-12-01 at 14:44 +0100, Pavel Březina wrote: > > >> >> On 11/24/2016 02:33 PM, Fabiano Fidêncio wrote: > > >> >>> The design page is done [0] and it's based on this discussion [1] we > > >> >>> had on this very same mailing list. A pull-request with the > > >> >>> implementation is already opened [2]. > > >> >>> > > >> >>> [0]: > > >> >>> https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders > > >> >>> [1]: > > >> >>> https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ > > >> >>> [2]: https://github.com/SSSD/sssd/pull/84 > > >> >> > > >> >> I think we should also provide 'disabled_services' option, to give > > >> >> admins a way to explicitly disable some responders if the don't want > > >> >> to > > >> >> used them. > > >> > > > >> > How would this work ? > > >> > > >> If responder is listed in disabled_services, it won't be allowed to > > >> start via socket activation. If disabling the socket as Fabiano > > >> mentioned in the other mail is enough, I'm fine with it, plese test. > > > > > > I am not sure this is a good behavior as clients will see a connection > > > being accept and then dropped, and may misbehave or report strange > > > errors. > > > > So, thinking a little bit about it Pavel's idea is not bad. > > If you have a list of "not allowed"/"disabled" services we can, at > > least, report the proper error when enabling the service. > > I don't know, to me it seems like if we are about to rely on systemd to > start the services we should just use the systemd facilities to manage > them. I'm not fond of the idea of yet another knob, or maybe I don't see > the benefit over disabling the socket. +1 Simo. -- Simo Sorce * Red Hat, Inc * New York ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On Thu, Dec 01, 2016 at 03:59:37PM +0100, Fabiano Fidêncio wrote: > On Thu, Dec 1, 2016 at 3:46 PM, Simo Sorce wrote: > > On Thu, 2016-12-01 at 15:22 +0100, Pavel Březina wrote: > >> On 12/01/2016 02:56 PM, Simo Sorce wrote: > >> > On Thu, 2016-12-01 at 14:44 +0100, Pavel Březina wrote: > >> >> On 11/24/2016 02:33 PM, Fabiano Fidêncio wrote: > >> >>> The design page is done [0] and it's based on this discussion [1] we > >> >>> had on this very same mailing list. A pull-request with the > >> >>> implementation is already opened [2]. > >> >>> > >> >>> [0]: > >> >>> https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders > >> >>> [1]: > >> >>> https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ > >> >>> [2]: https://github.com/SSSD/sssd/pull/84 > >> >> > >> >> I think we should also provide 'disabled_services' option, to give > >> >> admins a way to explicitly disable some responders if the don't want to > >> >> used them. > >> > > >> > How would this work ? > >> > >> If responder is listed in disabled_services, it won't be allowed to > >> start via socket activation. If disabling the socket as Fabiano > >> mentioned in the other mail is enough, I'm fine with it, plese test. > > > > I am not sure this is a good behavior as clients will see a connection > > being accept and then dropped, and may misbehave or report strange > > errors. > > So, thinking a little bit about it Pavel's idea is not bad. > If you have a list of "not allowed"/"disabled" services we can, at > least, report the proper error when enabling the service. I don't know, to me it seems like if we are about to rely on systemd to start the services we should just use the systemd facilities to manage them. I'm not fond of the idea of yet another knob, or maybe I don't see the benefit over disabling the socket. ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On Thu, Dec 1, 2016 at 3:46 PM, Simo Sorce wrote: > On Thu, 2016-12-01 at 15:22 +0100, Pavel Březina wrote: >> On 12/01/2016 02:56 PM, Simo Sorce wrote: >> > On Thu, 2016-12-01 at 14:44 +0100, Pavel Březina wrote: >> >> On 11/24/2016 02:33 PM, Fabiano Fidêncio wrote: >> >>> The design page is done [0] and it's based on this discussion [1] we >> >>> had on this very same mailing list. A pull-request with the >> >>> implementation is already opened [2]. >> >>> >> >>> [0]: >> >>> https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders >> >>> [1]: >> >>> https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ >> >>> [2]: https://github.com/SSSD/sssd/pull/84 >> >> >> >> I think we should also provide 'disabled_services' option, to give >> >> admins a way to explicitly disable some responders if the don't want to >> >> used them. >> > >> > How would this work ? >> >> If responder is listed in disabled_services, it won't be allowed to >> start via socket activation. If disabling the socket as Fabiano >> mentioned in the other mail is enough, I'm fine with it, plese test. > > I am not sure this is a good behavior as clients will see a connection > being accept and then dropped, and may misbehave or report strange > errors. So, thinking a little bit about it Pavel's idea is not bad. If you have a list of "not allowed"/"disabled" services we can, at least, report the proper error when enabling the service. Does this sound reasonable to you? > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > ___ > sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org > To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On Thu, 2016-12-01 at 15:22 +0100, Pavel Březina wrote: > On 12/01/2016 02:56 PM, Simo Sorce wrote: > > On Thu, 2016-12-01 at 14:44 +0100, Pavel Březina wrote: > >> On 11/24/2016 02:33 PM, Fabiano Fidêncio wrote: > >>> The design page is done [0] and it's based on this discussion [1] we > >>> had on this very same mailing list. A pull-request with the > >>> implementation is already opened [2]. > >>> > >>> [0]: > >>> https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders > >>> [1]: > >>> https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ > >>> [2]: https://github.com/SSSD/sssd/pull/84 > >> > >> I think we should also provide 'disabled_services' option, to give > >> admins a way to explicitly disable some responders if the don't want to > >> used them. > > > > How would this work ? > > If responder is listed in disabled_services, it won't be allowed to > start via socket activation. If disabling the socket as Fabiano > mentioned in the other mail is enough, I'm fine with it, plese test. I am not sure this is a good behavior as clients will see a connection being accept and then dropped, and may misbehave or report strange errors. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On Thu, 2016-12-01 at 15:19 +0100, Fabiano Fidêncio wrote: > On Thu, Dec 1, 2016 at 2:44 PM, Pavel Březina wrote: > > On 11/24/2016 02:33 PM, Fabiano Fidêncio wrote: > >> > >> The design page is done [0] and it's based on this discussion [1] we > >> had on this very same mailing list. A pull-request with the > >> implementation is already opened [2]. > >> > >> [0]: > >> https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders > >> [1]: > >> https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ > >> [2]: htatps://github.com/SSSD/sssd/pull/84 > > > > > > I think we should also provide 'disabled_services' option, to give admins a > > way to explicitly disable some responders if the don't want to used them. > > I have to double check a few things here but, AFAIU, just having the > socket disabled (systemctl disable sssd-@responder@.socket) should be > enough. I guess I misunderstood what ou mean by "provide 'disabled_services' option", I though you wanted to add that option to sssd.conf Simo. -- Simo Sorce * Red Hat, Inc * New York ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On 12/01/2016 02:56 PM, Simo Sorce wrote: On Thu, 2016-12-01 at 14:44 +0100, Pavel Březina wrote: On 11/24/2016 02:33 PM, Fabiano Fidêncio wrote: The design page is done [0] and it's based on this discussion [1] we had on this very same mailing list. A pull-request with the implementation is already opened [2]. [0]: https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders [1]: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ [2]: https://github.com/SSSD/sssd/pull/84 I think we should also provide 'disabled_services' option, to give admins a way to explicitly disable some responders if the don't want to used them. How would this work ? If responder is listed in disabled_services, it won't be allowed to start via socket activation. If disabling the socket as Fabiano mentioned in the other mail is enough, I'm fine with it, plese test. ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On Thu, Dec 1, 2016 at 2:44 PM, Pavel Březina wrote: > On 11/24/2016 02:33 PM, Fabiano Fidêncio wrote: >> >> The design page is done [0] and it's based on this discussion [1] we >> had on this very same mailing list. A pull-request with the >> implementation is already opened [2]. >> >> [0]: >> https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders >> [1]: >> https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ >> [2]: htatps://github.com/SSSD/sssd/pull/84 > > > I think we should also provide 'disabled_services' option, to give admins a > way to explicitly disable some responders if the don't want to used them. I have to double check a few things here but, AFAIU, just having the socket disabled (systemctl disable sssd-@responder@.socket) should be enough. > > ___ > sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org > To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On Thu, 2016-12-01 at 14:44 +0100, Pavel Březina wrote: > On 11/24/2016 02:33 PM, Fabiano Fidêncio wrote: > > The design page is done [0] and it's based on this discussion [1] we > > had on this very same mailing list. A pull-request with the > > implementation is already opened [2]. > > > > [0]: > > https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders > > [1]: > > https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ > > [2]: https://github.com/SSSD/sssd/pull/84 > > I think we should also provide 'disabled_services' option, to give > admins a way to explicitly disable some responders if the don't want to > used them. How would this work ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On 11/24/2016 02:33 PM, Fabiano Fidêncio wrote: The design page is done [0] and it's based on this discussion [1] we had on this very same mailing list. A pull-request with the implementation is already opened [2]. [0]: https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders [1]: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ [2]: https://github.com/SSSD/sssd/pull/84 I think we should also provide 'disabled_services' option, to give admins a way to explicitly disable some responders if the don't want to used them. ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On 11/29/2016 01:20 PM, Jakub Hrozek wrote: On Tue, Nov 29, 2016 at 12:55:58PM +0100, Lukas Slebodnik wrote: On (29/11/16 12:13), Fabiano Fidêncio wrote: On Tue, Nov 29, 2016 at 10:24 AM, Fabiano Fidêncio wrote: On Tue, Nov 29, 2016 at 10:01 AM, Lukas Slebodnik wrote: On (28/11/16 11:27), Jakub Hrozek wrote: On Mon, Nov 28, 2016 at 10:57:44AM +0100, Pavel Březina wrote: On 11/28/2016 10:47 AM, Jakub Hrozek wrote: On Thu, Nov 24, 2016 at 02:33:04PM +0100, Fabiano Fidêncio wrote: The design page is done [0] and it's based on this discussion [1] we had on this very same mailing list. A pull-request with the implementation is already opened [2]. [0]: https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders [1]: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ [2]: https://github.com/SSSD/sssd/pull/84 The full text of c&p here: In general looks good to me, but note that I was involved a bit with Fabiano in the discussion, so my view might be tainted. I finally got to it. The design page looks good and I'll start reviewing the patches. The only think I wonder about is whether we want to pass parameters " --uid 0 --gid 0 --debug-to-files" or we will read the from sssd.conf? I prefer reading them. Also what do we use the private sockets for? It is used only for root? Yes, that's where we route PAM requests started by UID 0 to. For example. The nss responder need't run as root. It does not require any extra privileges. And the privileges are dropped as soon as possible. The only issue might be with switching from root to non-root. A responder need to change owner of log files. But it could be solved with ExecStartPre in service file e.g. ExecStartPre=/usr/bin/chown sssd:sssd /var/log/sssd/sssd_nss.log ExecStart=/usr/libexec/sssd/sssd_nss --debug-to-files User=sssd Group=sssd PermissionsStartOnly=true @see the explanation of PermissionsStartOnly in man 5 systemd.service I like the suggestion. But I also would like to ask which are the responders that have to executed as root? This question still stands ... We have the following responders: autofs, ifp, nss, pac, pam, ssh and sudo. All of those can run as sssd user? sh$ cd src/responder/ sh$ git grep server_setup . autofs/autofssrv.c:ret = server_setup("sssd[autofs]", 0, uid, gid, ifp/ifpsrv.c:ret = server_setup("sssd[ifp]", 0, 0, 0, nss/nsssrv.c:ret = server_setup("sssd[nss]", 0, uid, gid, CONFDB_NSS_CONF_ENTRY, pac/pacsrv.c:ret = server_setup("sssd[pac]", 0, uid, gid, pam/pamsrv.c: * in server_setup() */ pam/pamsrv.c:ret = server_setup("sssd[pam]", 0, uid, gid, CONFDB_PAM_CONF_ENTRY, &main_ctx); secrets/secsrv.c:ret = server_setup("sssd[secrets]", 0, uid, gid, CONFDB_SEC_CONF_ENTRY, ssh/sshsrv.c:ret = server_setup("sssd[ssh]", 0, uid, gid, sudo/sudosrv.c:ret = server_setup("sssd[sudo]", 0, uid, gid, CONFDB_SUDO_CONF_ENTRY, As you can see only ifp responder uses hardcoded values (uid=0, gid=0) instead of values passed from command line. This was IIRC because of the OpenLMI config-changing interface, so I think this requirement can be removed. Yes. ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On Tue, Nov 29, 2016 at 12:55:58PM +0100, Lukas Slebodnik wrote: > On (29/11/16 12:13), Fabiano Fidêncio wrote: > >On Tue, Nov 29, 2016 at 10:24 AM, Fabiano Fidêncio > >wrote: > >> On Tue, Nov 29, 2016 at 10:01 AM, Lukas Slebodnik > >> wrote: > >>> On (28/11/16 11:27), Jakub Hrozek wrote: > On Mon, Nov 28, 2016 at 10:57:44AM +0100, Pavel Březina wrote: > > On 11/28/2016 10:47 AM, Jakub Hrozek wrote: > > > On Thu, Nov 24, 2016 at 02:33:04PM +0100, Fabiano Fidêncio wrote: > > > > The design page is done [0] and it's based on this discussion [1] we > > > > had on this very same mailing list. A pull-request with the > > > > implementation is already opened [2]. > > > > > > > > [0]: > > > > https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders > > > > [1]: > > > > https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ > > > > [2]: https://github.com/SSSD/sssd/pull/84 > > > > > > > > The full text of c&p here: > > > > > > In general looks good to me, but note that I was involved a bit with > > > Fabiano in the discussion, so my view might be tainted. > > > > I finally got to it. The design page looks good and I'll start > > reviewing the > > patches. > > > > The only think I wonder about is whether we want to pass parameters " > > --uid > > 0 --gid 0 --debug-to-files" or we will read the from sssd.conf? I prefer > > reading them. > > > > Also what do we use the private sockets for? It is used only for root? > > Yes, that's where we route PAM requests started by UID 0 to. > > >>> For example. The nss responder need't run as root. It does not require > >>> any extra privileges. And the privileges are dropped as soon as possible. > >>> The only issue might be with switching from root to non-root. > >>> A responder need to change owner of log files. > >>> But it could be solved with ExecStartPre in service file > >>> > >>> e.g. > >>> ExecStartPre=/usr/bin/chown sssd:sssd /var/log/sssd/sssd_nss.log > >>> ExecStart=/usr/libexec/sssd/sssd_nss --debug-to-files > >>> User=sssd > >>> Group=sssd > >>> PermissionsStartOnly=true > >>> > >>> @see the explanation of PermissionsStartOnly in man 5 systemd.service > >> > >> I like the suggestion. But I also would like to ask which are the > >> responders that have to executed as root? > > > >This question still stands ... > > > >We have the following responders: autofs, ifp, nss, pac, pam, ssh and sudo. > >All of those can run as sssd user? > > > sh$ cd src/responder/ > > sh$ git grep server_setup . > autofs/autofssrv.c:ret = server_setup("sssd[autofs]", 0, uid, gid, > ifp/ifpsrv.c:ret = server_setup("sssd[ifp]", 0, 0, 0, > nss/nsssrv.c:ret = server_setup("sssd[nss]", 0, uid, gid, > CONFDB_NSS_CONF_ENTRY, > pac/pacsrv.c:ret = server_setup("sssd[pac]", 0, uid, gid, > pam/pamsrv.c: * in server_setup() */ > pam/pamsrv.c:ret = server_setup("sssd[pam]", 0, uid, gid, > CONFDB_PAM_CONF_ENTRY, &main_ctx); > secrets/secsrv.c:ret = server_setup("sssd[secrets]", 0, uid, gid, > CONFDB_SEC_CONF_ENTRY, > ssh/sshsrv.c:ret = server_setup("sssd[ssh]", 0, uid, gid, > sudo/sudosrv.c:ret = server_setup("sssd[sudo]", 0, uid, gid, > CONFDB_SUDO_CONF_ENTRY, > > As you can see only ifp responder uses hardcoded values (uid=0, gid=0) > instead of values passed from command line. This was IIRC because of the OpenLMI config-changing interface, so I think this requirement can be removed. > > Most of responders are quite dummy and does not require any extra privileges. > they either can found data in cache or request data from backend. > Backends are more complicated because the most of logic is there > but they are not related to your work with socket activated services atm. > > LS > ___ > sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org > To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On (29/11/16 12:13), Fabiano Fidêncio wrote: >On Tue, Nov 29, 2016 at 10:24 AM, Fabiano Fidêncio wrote: >> On Tue, Nov 29, 2016 at 10:01 AM, Lukas Slebodnik >> wrote: >>> On (28/11/16 11:27), Jakub Hrozek wrote: On Mon, Nov 28, 2016 at 10:57:44AM +0100, Pavel Březina wrote: > On 11/28/2016 10:47 AM, Jakub Hrozek wrote: > > On Thu, Nov 24, 2016 at 02:33:04PM +0100, Fabiano Fidêncio wrote: > > > The design page is done [0] and it's based on this discussion [1] we > > > had on this very same mailing list. A pull-request with the > > > implementation is already opened [2]. > > > > > > [0]: > > > https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders > > > [1]: > > > https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ > > > [2]: https://github.com/SSSD/sssd/pull/84 > > > > > > The full text of c&p here: > > > > In general looks good to me, but note that I was involved a bit with > > Fabiano in the discussion, so my view might be tainted. > > I finally got to it. The design page looks good and I'll start reviewing > the > patches. > > The only think I wonder about is whether we want to pass parameters " > --uid > 0 --gid 0 --debug-to-files" or we will read the from sssd.conf? I prefer > reading them. > > Also what do we use the private sockets for? It is used only for root? Yes, that's where we route PAM requests started by UID 0 to. >>> For example. The nss responder need't run as root. It does not require >>> any extra privileges. And the privileges are dropped as soon as possible. >>> The only issue might be with switching from root to non-root. >>> A responder need to change owner of log files. >>> But it could be solved with ExecStartPre in service file >>> >>> e.g. >>> ExecStartPre=/usr/bin/chown sssd:sssd /var/log/sssd/sssd_nss.log >>> ExecStart=/usr/libexec/sssd/sssd_nss --debug-to-files >>> User=sssd >>> Group=sssd >>> PermissionsStartOnly=true >>> >>> @see the explanation of PermissionsStartOnly in man 5 systemd.service >> >> I like the suggestion. But I also would like to ask which are the >> responders that have to executed as root? > >This question still stands ... > >We have the following responders: autofs, ifp, nss, pac, pam, ssh and sudo. >All of those can run as sssd user? > sh$ cd src/responder/ sh$ git grep server_setup . autofs/autofssrv.c:ret = server_setup("sssd[autofs]", 0, uid, gid, ifp/ifpsrv.c:ret = server_setup("sssd[ifp]", 0, 0, 0, nss/nsssrv.c:ret = server_setup("sssd[nss]", 0, uid, gid, CONFDB_NSS_CONF_ENTRY, pac/pacsrv.c:ret = server_setup("sssd[pac]", 0, uid, gid, pam/pamsrv.c: * in server_setup() */ pam/pamsrv.c:ret = server_setup("sssd[pam]", 0, uid, gid, CONFDB_PAM_CONF_ENTRY, &main_ctx); secrets/secsrv.c:ret = server_setup("sssd[secrets]", 0, uid, gid, CONFDB_SEC_CONF_ENTRY, ssh/sshsrv.c:ret = server_setup("sssd[ssh]", 0, uid, gid, sudo/sudosrv.c:ret = server_setup("sssd[sudo]", 0, uid, gid, CONFDB_SUDO_CONF_ENTRY, As you can see only ifp responder uses hardcoded values (uid=0, gid=0) instead of values passed from command line. Most of responders are quite dummy and does not require any extra privileges. they either can found data in cache or request data from backend. Backends are more complicated because the most of logic is there but they are not related to your work with socket activated services atm. LS ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On Tue, Nov 29, 2016 at 10:24 AM, Fabiano Fidêncio wrote: > On Tue, Nov 29, 2016 at 10:01 AM, Lukas Slebodnik wrote: >> On (28/11/16 11:27), Jakub Hrozek wrote: >>>On Mon, Nov 28, 2016 at 10:57:44AM +0100, Pavel Březina wrote: On 11/28/2016 10:47 AM, Jakub Hrozek wrote: > On Thu, Nov 24, 2016 at 02:33:04PM +0100, Fabiano Fidêncio wrote: > > The design page is done [0] and it's based on this discussion [1] we > > had on this very same mailing list. A pull-request with the > > implementation is already opened [2]. > > > > [0]: > > https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders > > [1]: > > https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ > > [2]: https://github.com/SSSD/sssd/pull/84 > > > > The full text of c&p here: > > In general looks good to me, but note that I was involved a bit with > Fabiano in the discussion, so my view might be tainted. I finally got to it. The design page looks good and I'll start reviewing the patches. The only think I wonder about is whether we want to pass parameters " --uid 0 --gid 0 --debug-to-files" or we will read the from sssd.conf? I prefer reading them. Also what do we use the private sockets for? It is used only for root? >>> >>>Yes, that's where we route PAM requests started by UID 0 to. >>> >> For example. The nss responder need't run as root. It does not require >> any extra privileges. And the privileges are dropped as soon as possible. >> The only issue might be with switching from root to non-root. >> A responder need to change owner of log files. >> But it could be solved with ExecStartPre in service file >> >> e.g. >> ExecStartPre=/usr/bin/chown sssd:sssd /var/log/sssd/sssd_nss.log >> ExecStart=/usr/libexec/sssd/sssd_nss --debug-to-files >> User=sssd >> Group=sssd >> PermissionsStartOnly=true >> >> @see the explanation of PermissionsStartOnly in man 5 systemd.service > > I like the suggestion. But I also would like to ask which are the > responders that have to executed as root? This question still stands ... We have the following responders: autofs, ifp, nss, pac, pam, ssh and sudo. All of those can run as sssd user? > > Best Regards, > -- > Fabiano Fidêncio ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On Tue, Nov 29, 2016 at 11:48:31AM +0100, Lukas Slebodnik wrote: > On (29/11/16 11:03), Jakub Hrozek wrote: > >On Tue, Nov 29, 2016 at 10:50:31AM +0100, Lukas Slebodnik wrote: > >> On (29/11/16 10:27), Jakub Hrozek wrote: > >> >On Tue, Nov 29, 2016 at 10:01:58AM +0100, Lukas Slebodnik wrote: > >> >> On (28/11/16 11:27), Jakub Hrozek wrote: > >> >> >On Mon, Nov 28, 2016 at 10:57:44AM +0100, Pavel Březina wrote: > >> >> >> On 11/28/2016 10:47 AM, Jakub Hrozek wrote: > >> >> >> > On Thu, Nov 24, 2016 at 02:33:04PM +0100, Fabiano Fidêncio wrote: > >> >> >> > > The design page is done [0] and it's based on this discussion > >> >> >> > > [1] we > >> >> >> > > had on this very same mailing list. A pull-request with the > >> >> >> > > implementation is already opened [2]. > >> >> >> > > > >> >> >> > > [0]: > >> >> >> > > https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders > >> >> >> > > [1]: > >> >> >> > > https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ > >> >> >> > > [2]: https://github.com/SSSD/sssd/pull/84 > >> >> >> > > > >> >> >> > > The full text of c&p here: > >> >> >> > > >> >> >> > In general looks good to me, but note that I was involved a bit > >> >> >> > with > >> >> >> > Fabiano in the discussion, so my view might be tainted. > >> >> >> > >> >> >> I finally got to it. The design page looks good and I'll start > >> >> >> reviewing the > >> >> >> patches. > >> >> >> > >> >> >> The only think I wonder about is whether we want to pass parameters > >> >> >> " --uid > >> >> >> 0 --gid 0 --debug-to-files" or we will read the from sssd.conf? I > >> >> >> prefer > >> >> >> reading them. > >> >> >> > >> >> >> Also what do we use the private sockets for? It is used only for > >> >> >> root? > > > >This is the question, right? What do we use the private sockets for, > >like this one: > >/var/lib/sss/pipes/private/pam > >as opposed to this one: > >/var/lib/sss/pipes/pam > > > >> >> > > >> >> >Yes, that's where we route PAM requests started by UID 0 to. > >> >> > > >> >> For example. The nss responder need't run as root. > >> > > >> >I don't think this is about the identity the responder runs at, but > >> >about the identity of the client who talks to the responder socket, no? > >> > > >> I do not understant. Could you elaborate or provide an example? > >> Where you can see a problem with pure systemd solution for > >> unprivileged responders. We need to provide service files anyway. > > > >So provided I'm answering the right question :) the logic that routes > >the PAM request to /var/lib/sss/pipes/private/pam or > >/var/lib/sss/pipes/pam is in sss_pam_make_request(). If the PAM > >application is running as UID 0, then the PAM module writes to > ^^^ > how is it related to running pam responder as UID 0? It is not, the question earlier was "Also what do we use the private sockets for? It is used only for root?" ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On (29/11/16 11:03), Jakub Hrozek wrote: >On Tue, Nov 29, 2016 at 10:50:31AM +0100, Lukas Slebodnik wrote: >> On (29/11/16 10:27), Jakub Hrozek wrote: >> >On Tue, Nov 29, 2016 at 10:01:58AM +0100, Lukas Slebodnik wrote: >> >> On (28/11/16 11:27), Jakub Hrozek wrote: >> >> >On Mon, Nov 28, 2016 at 10:57:44AM +0100, Pavel Březina wrote: >> >> >> On 11/28/2016 10:47 AM, Jakub Hrozek wrote: >> >> >> > On Thu, Nov 24, 2016 at 02:33:04PM +0100, Fabiano Fidêncio wrote: >> >> >> > > The design page is done [0] and it's based on this discussion [1] >> >> >> > > we >> >> >> > > had on this very same mailing list. A pull-request with the >> >> >> > > implementation is already opened [2]. >> >> >> > > >> >> >> > > [0]: >> >> >> > > https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders >> >> >> > > [1]: >> >> >> > > https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ >> >> >> > > [2]: https://github.com/SSSD/sssd/pull/84 >> >> >> > > >> >> >> > > The full text of c&p here: >> >> >> > >> >> >> > In general looks good to me, but note that I was involved a bit with >> >> >> > Fabiano in the discussion, so my view might be tainted. >> >> >> >> >> >> I finally got to it. The design page looks good and I'll start >> >> >> reviewing the >> >> >> patches. >> >> >> >> >> >> The only think I wonder about is whether we want to pass parameters " >> >> >> --uid >> >> >> 0 --gid 0 --debug-to-files" or we will read the from sssd.conf? I >> >> >> prefer >> >> >> reading them. >> >> >> >> >> >> Also what do we use the private sockets for? It is used only for root? > >This is the question, right? What do we use the private sockets for, >like this one: >/var/lib/sss/pipes/private/pam >as opposed to this one: >/var/lib/sss/pipes/pam > >> >> > >> >> >Yes, that's where we route PAM requests started by UID 0 to. >> >> > >> >> For example. The nss responder need't run as root. >> > >> >I don't think this is about the identity the responder runs at, but >> >about the identity of the client who talks to the responder socket, no? >> > >> I do not understant. Could you elaborate or provide an example? >> Where you can see a problem with pure systemd solution for >> unprivileged responders. We need to provide service files anyway. > >So provided I'm answering the right question :) the logic that routes >the PAM request to /var/lib/sss/pipes/private/pam or >/var/lib/sss/pipes/pam is in sss_pam_make_request(). If the PAM >application is running as UID 0, then the PAM module writes to ^^^ how is it related to running pam responder as UID 0? >SSS_PAM_PRIV_SOCKET_NAME, otherwise it writes to SSS_PAM_SOCKET_NAME. Both sockets are created in function *pam_process_init* which is called after dropping privileges in *server_setup*. So I cannot see any problem for starting sssd_pam responder as unprivileged user which would be done by systemd. LS ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On Tue, Nov 29, 2016 at 11:28 AM, Sumit Bose wrote: > On Thu, Nov 24, 2016 at 02:33:04PM +0100, Fabiano Fidêncio wrote: >> The design page is done [0] and it's based on this discussion [1] we >> had on this very same mailing list. A pull-request with the >> implementation is already opened [2]. >> >> [0]: >> https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders >> [1]: >> https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ >> [2]: https://github.com/SSSD/sssd/pull/84 >> >> The full text of c&p here: > > Hi Fabiano, > > thank you for the design page. > >> >> = Socket Activatable Responders = >> > ... >> KCM >> The KCM responder is only seldom needed, when libkrb5 needs to access > > I'm not sure id 'seldom' is correct here. It will be used by mainly > during authentication but since it might be to default storage for any > Kerberos credential it will be use by the user for any kind of > Kerberos/GSSAPI related authentication to services. > >> the credentials store. At the same time, the KCM responder must be >> running if the Kerberos credentials cache defaults to `KCM`. >> Socket-activating the responder would solve both of these cases. >> > > But my main question is about the monitor and > /var/lib/sss/db/config.ldb. If I understand the design correctly the > monitor will still run and create config.ldb which is good because then > all socket-activated components will see the same config. So a > configuration change required a restart of the monitor. How will the > socket activated services handled in this case. Will the monitor shut > them down or is systemd smart enough to see that the "parent" service is > shut down and will shutdown the children as well. systemd is smart enough to do that, or almost. :-) Having "PartOf=sssd.service" as part of responders' unit files is enough to make then restart/shutdown any time systemd is restarted/shutdown. Best Regards, ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On Thu, Nov 24, 2016 at 02:33:04PM +0100, Fabiano Fidêncio wrote: > The design page is done [0] and it's based on this discussion [1] we > had on this very same mailing list. A pull-request with the > implementation is already opened [2]. > > [0]: https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders > [1]: > https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ > [2]: https://github.com/SSSD/sssd/pull/84 > > The full text of c&p here: Hi Fabiano, thank you for the design page. > > = Socket Activatable Responders = > ... > KCM > The KCM responder is only seldom needed, when libkrb5 needs to access I'm not sure id 'seldom' is correct here. It will be used by mainly during authentication but since it might be to default storage for any Kerberos credential it will be use by the user for any kind of Kerberos/GSSAPI related authentication to services. > the credentials store. At the same time, the KCM responder must be > running if the Kerberos credentials cache defaults to `KCM`. > Socket-activating the responder would solve both of these cases. > But my main question is about the monitor and /var/lib/sss/db/config.ldb. If I understand the design correctly the monitor will still run and create config.ldb which is good because then all socket-activated components will see the same config. So a configuration change required a restart of the monitor. How will the socket activated services handled in this case. Will the monitor shut them down or is systemd smart enough to see that the "parent" service is shut down and will shutdown the children as well. bye, Sumit ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On Tue, Nov 29, 2016 at 10:50:31AM +0100, Lukas Slebodnik wrote: > On (29/11/16 10:27), Jakub Hrozek wrote: > >On Tue, Nov 29, 2016 at 10:01:58AM +0100, Lukas Slebodnik wrote: > >> On (28/11/16 11:27), Jakub Hrozek wrote: > >> >On Mon, Nov 28, 2016 at 10:57:44AM +0100, Pavel Březina wrote: > >> >> On 11/28/2016 10:47 AM, Jakub Hrozek wrote: > >> >> > On Thu, Nov 24, 2016 at 02:33:04PM +0100, Fabiano Fidêncio wrote: > >> >> > > The design page is done [0] and it's based on this discussion [1] we > >> >> > > had on this very same mailing list. A pull-request with the > >> >> > > implementation is already opened [2]. > >> >> > > > >> >> > > [0]: > >> >> > > https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders > >> >> > > [1]: > >> >> > > https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ > >> >> > > [2]: https://github.com/SSSD/sssd/pull/84 > >> >> > > > >> >> > > The full text of c&p here: > >> >> > > >> >> > In general looks good to me, but note that I was involved a bit with > >> >> > Fabiano in the discussion, so my view might be tainted. > >> >> > >> >> I finally got to it. The design page looks good and I'll start > >> >> reviewing the > >> >> patches. > >> >> > >> >> The only think I wonder about is whether we want to pass parameters " > >> >> --uid > >> >> 0 --gid 0 --debug-to-files" or we will read the from sssd.conf? I prefer > >> >> reading them. > >> >> > >> >> Also what do we use the private sockets for? It is used only for root? This is the question, right? What do we use the private sockets for, like this one: /var/lib/sss/pipes/private/pam as opposed to this one: /var/lib/sss/pipes/pam > >> > > >> >Yes, that's where we route PAM requests started by UID 0 to. > >> > > >> For example. The nss responder need't run as root. > > > >I don't think this is about the identity the responder runs at, but > >about the identity of the client who talks to the responder socket, no? > > > I do not understant. Could you elaborate or provide an example? > Where you can see a problem with pure systemd solution for > unprivileged responders. We need to provide service files anyway. So provided I'm answering the right question :) the logic that routes the PAM request to /var/lib/sss/pipes/private/pam or /var/lib/sss/pipes/pam is in sss_pam_make_request(). If the PAM application is running as UID 0, then the PAM module writes to SSS_PAM_PRIV_SOCKET_NAME, otherwise it writes to SSS_PAM_SOCKET_NAME. ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On (29/11/16 10:30), Jakub Hrozek wrote: >On Tue, Nov 29, 2016 at 10:24:03AM +0100, Fabiano Fidêncio wrote: >> On Tue, Nov 29, 2016 at 10:01 AM, Lukas Slebodnik >> wrote: >> > On (28/11/16 11:27), Jakub Hrozek wrote: >> >>On Mon, Nov 28, 2016 at 10:57:44AM +0100, Pavel Březina wrote: >> >>> On 11/28/2016 10:47 AM, Jakub Hrozek wrote: >> >>> > On Thu, Nov 24, 2016 at 02:33:04PM +0100, Fabiano Fidêncio wrote: >> >>> > > The design page is done [0] and it's based on this discussion [1] we >> >>> > > had on this very same mailing list. A pull-request with the >> >>> > > implementation is already opened [2]. >> >>> > > >> >>> > > [0]: >> >>> > > https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders >> >>> > > [1]: >> >>> > > https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ >> >>> > > [2]: https://github.com/SSSD/sssd/pull/84 >> >>> > > >> >>> > > The full text of c&p here: >> >>> > >> >>> > In general looks good to me, but note that I was involved a bit with >> >>> > Fabiano in the discussion, so my view might be tainted. >> >>> >> >>> I finally got to it. The design page looks good and I'll start reviewing >> >>> the >> >>> patches. >> >>> >> >>> The only think I wonder about is whether we want to pass parameters " >> >>> --uid >> >>> 0 --gid 0 --debug-to-files" or we will read the from sssd.conf? I prefer >> >>> reading them. >> >>> >> >>> Also what do we use the private sockets for? It is used only for root? >> >> >> >>Yes, that's where we route PAM requests started by UID 0 to. >> >> >> > For example. The nss responder need't run as root. It does not require >> > any extra privileges. And the privileges are dropped as soon as possible. >> > The only issue might be with switching from root to non-root. >> > A responder need to change owner of log files. >> > But it could be solved with ExecStartPre in service file >> > >> > e.g. >> > ExecStartPre=/usr/bin/chown sssd:sssd /var/log/sssd/sssd_nss.log >> > ExecStart=/usr/libexec/sssd/sssd_nss --debug-to-files >> > User=sssd >> > Group=sssd >> > PermissionsStartOnly=true >> > >> > @see the explanation of PermissionsStartOnly in man 5 systemd.service >> >> I like the suggestion. But I also would like to ask which are the >> responders that have to executed as root? > >I guess ideally none, especially some security certifications require >that no code that authenticates users runs as root. But we're not there yet, >see for example: >https://fedorahosted.org/sssd/ticket/3014 it iss not related to responder. >or: >https://fedorahosted.org/sssd/ticket/3099 > it is not related to responder either. >btw now that you nuked the config changing API in IFP, it should be >possible for IFP to drop privileges after it connects to the system bus >(or even before? I'm really not sure anymore). > >Can we have a ticket to examine if we can start IFP as the sssd user? ifp responder can be started with --uid 0 --gid 0 and not with --unprivileged-start. We can convert to unprivileged-start later if possible. So far I cannot see any big issue. Circular dependency between resolving sssd user and files provider and be solved with hardcoded UID GID. LS ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On (29/11/16 10:27), Jakub Hrozek wrote: >On Tue, Nov 29, 2016 at 10:01:58AM +0100, Lukas Slebodnik wrote: >> On (28/11/16 11:27), Jakub Hrozek wrote: >> >On Mon, Nov 28, 2016 at 10:57:44AM +0100, Pavel Březina wrote: >> >> On 11/28/2016 10:47 AM, Jakub Hrozek wrote: >> >> > On Thu, Nov 24, 2016 at 02:33:04PM +0100, Fabiano Fidêncio wrote: >> >> > > The design page is done [0] and it's based on this discussion [1] we >> >> > > had on this very same mailing list. A pull-request with the >> >> > > implementation is already opened [2]. >> >> > > >> >> > > [0]: >> >> > > https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders >> >> > > [1]: >> >> > > https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ >> >> > > [2]: https://github.com/SSSD/sssd/pull/84 >> >> > > >> >> > > The full text of c&p here: >> >> > >> >> > In general looks good to me, but note that I was involved a bit with >> >> > Fabiano in the discussion, so my view might be tainted. >> >> >> >> I finally got to it. The design page looks good and I'll start reviewing >> >> the >> >> patches. >> >> >> >> The only think I wonder about is whether we want to pass parameters " >> >> --uid >> >> 0 --gid 0 --debug-to-files" or we will read the from sssd.conf? I prefer >> >> reading them. >> >> >> >> Also what do we use the private sockets for? It is used only for root? >> > >> >Yes, that's where we route PAM requests started by UID 0 to. >> > >> For example. The nss responder need't run as root. > >I don't think this is about the identity the responder runs at, but >about the identity of the client who talks to the responder socket, no? > I do not understant. Could you elaborate or provide an example? Where you can see a problem with pure systemd solution for unprivileged responders. We need to provide service files anyway. LS ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On Tue, Nov 29, 2016 at 10:24:03AM +0100, Fabiano Fidêncio wrote: > On Tue, Nov 29, 2016 at 10:01 AM, Lukas Slebodnik wrote: > > On (28/11/16 11:27), Jakub Hrozek wrote: > >>On Mon, Nov 28, 2016 at 10:57:44AM +0100, Pavel Březina wrote: > >>> On 11/28/2016 10:47 AM, Jakub Hrozek wrote: > >>> > On Thu, Nov 24, 2016 at 02:33:04PM +0100, Fabiano Fidêncio wrote: > >>> > > The design page is done [0] and it's based on this discussion [1] we > >>> > > had on this very same mailing list. A pull-request with the > >>> > > implementation is already opened [2]. > >>> > > > >>> > > [0]: > >>> > > https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders > >>> > > [1]: > >>> > > https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ > >>> > > [2]: https://github.com/SSSD/sssd/pull/84 > >>> > > > >>> > > The full text of c&p here: > >>> > > >>> > In general looks good to me, but note that I was involved a bit with > >>> > Fabiano in the discussion, so my view might be tainted. > >>> > >>> I finally got to it. The design page looks good and I'll start reviewing > >>> the > >>> patches. > >>> > >>> The only think I wonder about is whether we want to pass parameters " > >>> --uid > >>> 0 --gid 0 --debug-to-files" or we will read the from sssd.conf? I prefer > >>> reading them. > >>> > >>> Also what do we use the private sockets for? It is used only for root? > >> > >>Yes, that's where we route PAM requests started by UID 0 to. > >> > > For example. The nss responder need't run as root. It does not require > > any extra privileges. And the privileges are dropped as soon as possible. > > The only issue might be with switching from root to non-root. > > A responder need to change owner of log files. > > But it could be solved with ExecStartPre in service file > > > > e.g. > > ExecStartPre=/usr/bin/chown sssd:sssd /var/log/sssd/sssd_nss.log > > ExecStart=/usr/libexec/sssd/sssd_nss --debug-to-files > > User=sssd > > Group=sssd > > PermissionsStartOnly=true > > > > @see the explanation of PermissionsStartOnly in man 5 systemd.service > > I like the suggestion. But I also would like to ask which are the > responders that have to executed as root? I guess ideally none, especially some security certifications require that no code that authenticates users runs as root. But we're not there yet, see for example: https://fedorahosted.org/sssd/ticket/3014 or: https://fedorahosted.org/sssd/ticket/3099 btw now that you nuked the config changing API in IFP, it should be possible for IFP to drop privileges after it connects to the system bus (or even before? I'm really not sure anymore). Can we have a ticket to examine if we can start IFP as the sssd user? ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On Tue, Nov 29, 2016 at 10:01:58AM +0100, Lukas Slebodnik wrote: > On (28/11/16 11:27), Jakub Hrozek wrote: > >On Mon, Nov 28, 2016 at 10:57:44AM +0100, Pavel Březina wrote: > >> On 11/28/2016 10:47 AM, Jakub Hrozek wrote: > >> > On Thu, Nov 24, 2016 at 02:33:04PM +0100, Fabiano Fidêncio wrote: > >> > > The design page is done [0] and it's based on this discussion [1] we > >> > > had on this very same mailing list. A pull-request with the > >> > > implementation is already opened [2]. > >> > > > >> > > [0]: > >> > > https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders > >> > > [1]: > >> > > https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ > >> > > [2]: https://github.com/SSSD/sssd/pull/84 > >> > > > >> > > The full text of c&p here: > >> > > >> > In general looks good to me, but note that I was involved a bit with > >> > Fabiano in the discussion, so my view might be tainted. > >> > >> I finally got to it. The design page looks good and I'll start reviewing > >> the > >> patches. > >> > >> The only think I wonder about is whether we want to pass parameters " --uid > >> 0 --gid 0 --debug-to-files" or we will read the from sssd.conf? I prefer > >> reading them. > >> > >> Also what do we use the private sockets for? It is used only for root? > > > >Yes, that's where we route PAM requests started by UID 0 to. > > > For example. The nss responder need't run as root. I don't think this is about the identity the responder runs at, but about the identity of the client who talks to the responder socket, no? > It does not require > any extra privileges. And the privileges are dropped as soon as possible. > The only issue might be with switching from root to non-root. > A responder need to change owner of log files. > But it could be solved with ExecStartPre in service file > > e.g. > ExecStartPre=/usr/bin/chown sssd:sssd /var/log/sssd/sssd_nss.log > ExecStart=/usr/libexec/sssd/sssd_nss --debug-to-files > User=sssd > Group=sssd > PermissionsStartOnly=true > > @see the explanation of PermissionsStartOnly in man 5 systemd.service ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On Tue, Nov 29, 2016 at 10:01 AM, Lukas Slebodnik wrote: > On (28/11/16 11:27), Jakub Hrozek wrote: >>On Mon, Nov 28, 2016 at 10:57:44AM +0100, Pavel Březina wrote: >>> On 11/28/2016 10:47 AM, Jakub Hrozek wrote: >>> > On Thu, Nov 24, 2016 at 02:33:04PM +0100, Fabiano Fidêncio wrote: >>> > > The design page is done [0] and it's based on this discussion [1] we >>> > > had on this very same mailing list. A pull-request with the >>> > > implementation is already opened [2]. >>> > > >>> > > [0]: >>> > > https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders >>> > > [1]: >>> > > https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ >>> > > [2]: https://github.com/SSSD/sssd/pull/84 >>> > > >>> > > The full text of c&p here: >>> > >>> > In general looks good to me, but note that I was involved a bit with >>> > Fabiano in the discussion, so my view might be tainted. >>> >>> I finally got to it. The design page looks good and I'll start reviewing the >>> patches. >>> >>> The only think I wonder about is whether we want to pass parameters " --uid >>> 0 --gid 0 --debug-to-files" or we will read the from sssd.conf? I prefer >>> reading them. >>> >>> Also what do we use the private sockets for? It is used only for root? >> >>Yes, that's where we route PAM requests started by UID 0 to. >> > For example. The nss responder need't run as root. It does not require > any extra privileges. And the privileges are dropped as soon as possible. > The only issue might be with switching from root to non-root. > A responder need to change owner of log files. > But it could be solved with ExecStartPre in service file > > e.g. > ExecStartPre=/usr/bin/chown sssd:sssd /var/log/sssd/sssd_nss.log > ExecStart=/usr/libexec/sssd/sssd_nss --debug-to-files > User=sssd > Group=sssd > PermissionsStartOnly=true > > @see the explanation of PermissionsStartOnly in man 5 systemd.service I like the suggestion. But I also would like to ask which are the responders that have to executed as root? Best Regards, -- Fabiano Fidêncio ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On (29/11/16 10:01), Lukas Slebodnik wrote: >On (28/11/16 11:27), Jakub Hrozek wrote: >>On Mon, Nov 28, 2016 at 10:57:44AM +0100, Pavel Březina wrote: >>> On 11/28/2016 10:47 AM, Jakub Hrozek wrote: >>> > On Thu, Nov 24, 2016 at 02:33:04PM +0100, Fabiano Fidêncio wrote: >>> > > The design page is done [0] and it's based on this discussion [1] we >>> > > had on this very same mailing list. A pull-request with the >>> > > implementation is already opened [2]. >>> > > >>> > > [0]: >>> > > https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders >>> > > [1]: >>> > > https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ >>> > > [2]: https://github.com/SSSD/sssd/pull/84 >>> > > >>> > > The full text of c&p here: >>> > >>> > In general looks good to me, but note that I was involved a bit with >>> > Fabiano in the discussion, so my view might be tainted. >>> >>> I finally got to it. The design page looks good and I'll start reviewing the >>> patches. >>> >>> The only think I wonder about is whether we want to pass parameters " --uid >>> 0 --gid 0 --debug-to-files" or we will read the from sssd.conf? I prefer >>> reading them. >>> >>> Also what do we use the private sockets for? It is used only for root? >> >>Yes, that's where we route PAM requests started by UID 0 to. >> >For example. The nss responder need't run as root. It does not require >any extra privileges. And the privileges are dropped as soon as possible. >The only issue might be with switching from root to non-root. >A responder need to change owner of log files. >But it could be solved with ExecStartPre in service file > >e.g. >ExecStartPre=/usr/bin/chown sssd:sssd /var/log/sssd/sssd_nss.log >ExecStart=/usr/libexec/sssd/sssd_nss --debug-to-files >User=sssd >Group=sssd >PermissionsStartOnly=true > >@see the explanation of PermissionsStartOnly in man 5 systemd.service > Actually we might add new parameter "--unprivileged-start" which would be used for skiping calls of *chown_debug_file* + *become_user* and also maybe checking that process is not executed as root (uid != 0 && gid != 0) LS ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On (28/11/16 11:27), Jakub Hrozek wrote: >On Mon, Nov 28, 2016 at 10:57:44AM +0100, Pavel Březina wrote: >> On 11/28/2016 10:47 AM, Jakub Hrozek wrote: >> > On Thu, Nov 24, 2016 at 02:33:04PM +0100, Fabiano Fidêncio wrote: >> > > The design page is done [0] and it's based on this discussion [1] we >> > > had on this very same mailing list. A pull-request with the >> > > implementation is already opened [2]. >> > > >> > > [0]: >> > > https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders >> > > [1]: >> > > https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ >> > > [2]: https://github.com/SSSD/sssd/pull/84 >> > > >> > > The full text of c&p here: >> > >> > In general looks good to me, but note that I was involved a bit with >> > Fabiano in the discussion, so my view might be tainted. >> >> I finally got to it. The design page looks good and I'll start reviewing the >> patches. >> >> The only think I wonder about is whether we want to pass parameters " --uid >> 0 --gid 0 --debug-to-files" or we will read the from sssd.conf? I prefer >> reading them. >> >> Also what do we use the private sockets for? It is used only for root? > >Yes, that's where we route PAM requests started by UID 0 to. > For example. The nss responder need't run as root. It does not require any extra privileges. And the privileges are dropped as soon as possible. The only issue might be with switching from root to non-root. A responder need to change owner of log files. But it could be solved with ExecStartPre in service file e.g. ExecStartPre=/usr/bin/chown sssd:sssd /var/log/sssd/sssd_nss.log ExecStart=/usr/libexec/sssd/sssd_nss --debug-to-files User=sssd Group=sssd PermissionsStartOnly=true @see the explanation of PermissionsStartOnly in man 5 systemd.service LS ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On Mon, Nov 28, 2016 at 10:57:44AM +0100, Pavel Březina wrote: > On 11/28/2016 10:47 AM, Jakub Hrozek wrote: > > On Thu, Nov 24, 2016 at 02:33:04PM +0100, Fabiano Fidêncio wrote: > > > The design page is done [0] and it's based on this discussion [1] we > > > had on this very same mailing list. A pull-request with the > > > implementation is already opened [2]. > > > > > > [0]: > > > https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders > > > [1]: > > > https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ > > > [2]: https://github.com/SSSD/sssd/pull/84 > > > > > > The full text of c&p here: > > > > In general looks good to me, but note that I was involved a bit with > > Fabiano in the discussion, so my view might be tainted. > > I finally got to it. The design page looks good and I'll start reviewing the > patches. > > The only think I wonder about is whether we want to pass parameters " --uid > 0 --gid 0 --debug-to-files" or we will read the from sssd.conf? I prefer > reading them. > > Also what do we use the private sockets for? It is used only for root? Yes, that's where we route PAM requests started by UID 0 to. > > > The only question I have is actually something Stephen asked during > > review of the KCM design page -- there might be a situation where a > > periodic timer (like credentials renewal in KCM) might conflict with > > socket-activated responder time out. At worst, we can just disable the > > time out, or we can explore Stephen's suggestion there or do something > > else. But this problem is worth keeping in mind. > > Exploring Stephen's suggestion seem as a way to go at the moment. I wouldn't > disabling the timeout since then it doesn't need to be socket activated at > all because you loose all its benefits. > ___ > sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org > To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On 11/28/2016 10:47 AM, Jakub Hrozek wrote: On Thu, Nov 24, 2016 at 02:33:04PM +0100, Fabiano Fidêncio wrote: The design page is done [0] and it's based on this discussion [1] we had on this very same mailing list. A pull-request with the implementation is already opened [2]. [0]: https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders [1]: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ [2]: https://github.com/SSSD/sssd/pull/84 The full text of c&p here: In general looks good to me, but note that I was involved a bit with Fabiano in the discussion, so my view might be tainted. I finally got to it. The design page looks good and I'll start reviewing the patches. The only think I wonder about is whether we want to pass parameters " --uid 0 --gid 0 --debug-to-files" or we will read the from sssd.conf? I prefer reading them. Also what do we use the private sockets for? It is used only for root? The only question I have is actually something Stephen asked during review of the KCM design page -- there might be a situation where a periodic timer (like credentials renewal in KCM) might conflict with socket-activated responder time out. At worst, we can just disable the time out, or we can explore Stephen's suggestion there or do something else. But this problem is worth keeping in mind. Exploring Stephen's suggestion seem as a way to go at the moment. I wouldn't disabling the timeout since then it doesn't need to be socket activated at all because you loose all its benefits. ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: Design document - Socket-activatable responders
On Thu, Nov 24, 2016 at 02:33:04PM +0100, Fabiano Fidêncio wrote: > The design page is done [0] and it's based on this discussion [1] we > had on this very same mailing list. A pull-request with the > implementation is already opened [2]. > > [0]: https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders > [1]: > https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ > [2]: https://github.com/SSSD/sssd/pull/84 > > The full text of c&p here: In general looks good to me, but note that I was involved a bit with Fabiano in the discussion, so my view might be tainted. The only question I have is actually something Stephen asked during review of the KCM design page -- there might be a situation where a periodic timer (like credentials renewal in KCM) might conflict with socket-activated responder time out. At worst, we can just disable the time out, or we can explore Stephen's suggestion there or do something else. But this problem is worth keeping in mind. > > = Socket Activatable Responders = > > Related ticket(s): > * https://fedorahosted.org/sssd/ticket/2243 > * https://fedorahosted.org/sssd/ticket/3129 > > === Problem statement === > SSSD has some responders which don't have to be running all the time, > but could be socket-activated instead in platforms where it's > supported. That's the case, for instance, for the IFP, ssh and sudo > responders. > Making these responders socket-activated would provide a better use > experience, as these services could be started on-demand when a client > needs them and exist after a period of inactivity. Currently the admin > has to explicitly list all the services that might potentially be > needed in the `services` section and the processes have to be running > all the time. > > === Use cases === > > sssctl > As more and more features that had been added depending on the IFP > responder, we should make sure that the responder is activated on > demand and the admins doesn't have to activate it manually. > > KCM > The KCM responder is only seldom needed, when libkrb5 needs to access > the credentials store. At the same time, the KCM responder must be > running if the Kerberos credentials cache defaults to `KCM`. > Socket-activating the responder would solve both of these cases. > > autofs > The autofs responder is typically only needed when a share is about to > be mounted. > > === Overview of the solution === > The solution agreed on the mailing list is to add a new unit for each > one of the responders. Once a responder is started, it will > communicate to the monitor in order to let the monitor know that it's > up and the monitor will do the registration of the responder, which > basically consists in marking the service as started, increasing the > services' counter, getting the responder's configuratiom, adding the > responder to the service's list. > A configurable idle timeout will be implemented in each responder, as > part of this task, in order to exit the responder in case it's not > used for a few minutes. > > === Implementation details === > In order to achieve our goal we will need a small modification in > responders' common code in order to make it ready for > socket-activation, add some systemd units for each of the responders > and finally small changes in the monitor code in order to manage the > new activated service. > > The change in the responders' common code is quite trivial, just > chnage the sss_process_init code to call activate_unix_sockets() > istead of set_unix_socket(). Something like: > {{{ > -ret = set_unix_socket(rctx, conn_setup); > +ret = activate_unix_sockets(rctx, conn_setup); > }}} > > The units that have to be added for each responder must look like: > > sssd-@respon...@.service.in: > {{{ > [Unit] > Description=SSSD @responder@ Service responder > Documentation=man:sssd.conf(5) > Requires=sssd.service > PartOf=sssd.service > After=sssd.service > > [Install] > Also=sssd-@responder@.socket > > [Service] > ExecStart=@libexecdir@/sssd/sssd_@responder@ --uid 0 --gid 0 --debug-to-files > }}} > > sssd-@respon...@.socket.in: > {{{ > [Unit] > Description=SSSD @responder@ Service responder socket > Documentation=man:sssd.conf(5) > > [Socket] > ListenStream=@pipepath@/@responder@ > > [Install] > WantedBy=sockets.target > }}} > > Some responders may have more than one socket, which is the case of > PAM, so another unit will be needed. > > sssd-@respon...@-priv.socket.in: > {{{ > [Unit] > Description=SSSD @responder@ Service responder private socket > Documentation=man:sssd.conf(5) > > [Socket] > ListenStream=@pipepath@/private/@responder@ > > [Install] > WantedBy=sockets.target > }}} > > Last but not least, the IFP responder doesn't have a socket. It's > going to be D-Bus activated and some small changes will be required on > its D-Bus service unit. > {{{ > -Exec=@libexecdir@/sssd/sss_signal > +
[SSSD] Re: Design document - Socket-activatable responders
Hey fabiano, There are couple of spelling mistakes(*Bo**ld*) on DesignDoc Page: https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders consists in marking the service as started, increasing the services' counter, getting the responder's *configuratiom*, < he change in the responders' common code is quite trivial, just *chnage* the sss_process_init code to call activate_unix_sockets() < Thanks On 11/25/2016 04:34 AM, Fabiano Fidêncio wrote: > On Thu, Nov 24, 2016 at 2:33 PM, Fabiano Fidêncio wrote: >> The design page is done [0] and it's based on this discussion [1] we >> had on this very same mailing list. A pull-request with the >> implementation is already opened [2]. >> >> [0]: >> https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders >> [1]: >> https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ >> [2]: https://github.com/SSSD/sssd/pull/84 > Well, PR#94: https://github.com/SSSD/sssd/pull/94 > >> The full text of c&p here: >> >> = Socket Activatable Responders = >> >> Related ticket(s): >> * https://fedorahosted.org/sssd/ticket/2243 >> * https://fedorahosted.org/sssd/ticket/3129 >> >> === Problem statement === >> SSSD has some responders which don't have to be running all the time, >> but could be socket-activated instead in platforms where it's >> supported. That's the case, for instance, for the IFP, ssh and sudo >> responders. >> Making these responders socket-activated would provide a better use >> experience, as these services could be started on-demand when a client >> needs them and exist after a period of inactivity. Currently the admin >> has to explicitly list all the services that might potentially be >> needed in the `services` section and the processes have to be running >> all the time. >> >> === Use cases === >> >> sssctl >> As more and more features that had been added depending on the IFP >> responder, we should make sure that the responder is activated on >> demand and the admins doesn't have to activate it manually. >> >> KCM >> The KCM responder is only seldom needed, when libkrb5 needs to access >> the credentials store. At the same time, the KCM responder must be >> running if the Kerberos credentials cache defaults to `KCM`. >> Socket-activating the responder would solve both of these cases. >> >> autofs >> The autofs responder is typically only needed when a share is about to >> be mounted. >> >> === Overview of the solution === >> The solution agreed on the mailing list is to add a new unit for each >> one of the responders. Once a responder is started, it will >> communicate to the monitor in order to let the monitor know that it's >> up and the monitor will do the registration of the responder, which >> basically consists in marking the service as started, increasing the >> services' counter, getting the responder's configuratiom, adding the >> responder to the service's list. >> A configurable idle timeout will be implemented in each responder, as >> part of this task, in order to exit the responder in case it's not >> used for a few minutes. >> >> === Implementation details === >> In order to achieve our goal we will need a small modification in >> responders' common code in order to make it ready for >> socket-activation, add some systemd units for each of the responders >> and finally small changes in the monitor code in order to manage the >> new activated service. >> >> The change in the responders' common code is quite trivial, just >> chnage the sss_process_init code to call activate_unix_sockets() >> istead of set_unix_socket(). Something like: >> {{{ >> -ret = set_unix_socket(rctx, conn_setup); >> +ret = activate_unix_sockets(rctx, conn_setup); >> }}} >> >> The units that have to be added for each responder must look like: >> >> sssd-@respon...@.service.in: >> {{{ >> [Unit] >> Description=SSSD @responder@ Service responder >> Documentation=man:sssd.conf(5) >> Requires=sssd.service >> PartOf=sssd.service >> After=sssd.service >> >> [Install] >> Also=sssd-@responder@.socket >> >> [Service] >> ExecStart=@libexecdir@/sssd/sssd_@responder@ --uid 0 --gid 0 --debug-to-files >> }}} >> >> sssd-@respon...@.socket.in: >> {{{ >> [Unit] >> Description=SSSD @responder@ Service responder socket >> Documentation=man:sssd.conf(5) >> >> [Socket] >> ListenStream=@pipepath@/@responder@ >> >> [Install] >> WantedBy=sockets.target >> }}} >> >> Some responders may have more than one socket, which is the case of >> PAM, so another unit will be needed. >> >> sssd-@respon...@-priv.socket.in: >> {{{ >> [Unit] >> Description=SSSD @responder@ Service responder private socket >> Documentation=man:sssd.conf(5) >> >> [Socket] >> ListenStream=@pipepath@/private/@responder@ >> >> [Install] >> WantedBy=sockets.target >> }}} >> >> Last but not least, the IFP responder doesn't have a socket. It's >> going to be D-Bus activated and some sma
[SSSD] Re: Design document - Socket-activatable responders
On Thu, Nov 24, 2016 at 2:33 PM, Fabiano Fidêncio wrote: > The design page is done [0] and it's based on this discussion [1] we > had on this very same mailing list. A pull-request with the > implementation is already opened [2]. > > [0]: https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders > [1]: > https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ > [2]: https://github.com/SSSD/sssd/pull/84 Well, PR#94: https://github.com/SSSD/sssd/pull/94 > > The full text of c&p here: > > = Socket Activatable Responders = > > Related ticket(s): > * https://fedorahosted.org/sssd/ticket/2243 > * https://fedorahosted.org/sssd/ticket/3129 > > === Problem statement === > SSSD has some responders which don't have to be running all the time, > but could be socket-activated instead in platforms where it's > supported. That's the case, for instance, for the IFP, ssh and sudo > responders. > Making these responders socket-activated would provide a better use > experience, as these services could be started on-demand when a client > needs them and exist after a period of inactivity. Currently the admin > has to explicitly list all the services that might potentially be > needed in the `services` section and the processes have to be running > all the time. > > === Use cases === > > sssctl > As more and more features that had been added depending on the IFP > responder, we should make sure that the responder is activated on > demand and the admins doesn't have to activate it manually. > > KCM > The KCM responder is only seldom needed, when libkrb5 needs to access > the credentials store. At the same time, the KCM responder must be > running if the Kerberos credentials cache defaults to `KCM`. > Socket-activating the responder would solve both of these cases. > > autofs > The autofs responder is typically only needed when a share is about to > be mounted. > > === Overview of the solution === > The solution agreed on the mailing list is to add a new unit for each > one of the responders. Once a responder is started, it will > communicate to the monitor in order to let the monitor know that it's > up and the monitor will do the registration of the responder, which > basically consists in marking the service as started, increasing the > services' counter, getting the responder's configuratiom, adding the > responder to the service's list. > A configurable idle timeout will be implemented in each responder, as > part of this task, in order to exit the responder in case it's not > used for a few minutes. > > === Implementation details === > In order to achieve our goal we will need a small modification in > responders' common code in order to make it ready for > socket-activation, add some systemd units for each of the responders > and finally small changes in the monitor code in order to manage the > new activated service. > > The change in the responders' common code is quite trivial, just > chnage the sss_process_init code to call activate_unix_sockets() > istead of set_unix_socket(). Something like: > {{{ > -ret = set_unix_socket(rctx, conn_setup); > +ret = activate_unix_sockets(rctx, conn_setup); > }}} > > The units that have to be added for each responder must look like: > > sssd-@respon...@.service.in: > {{{ > [Unit] > Description=SSSD @responder@ Service responder > Documentation=man:sssd.conf(5) > Requires=sssd.service > PartOf=sssd.service > After=sssd.service > > [Install] > Also=sssd-@responder@.socket > > [Service] > ExecStart=@libexecdir@/sssd/sssd_@responder@ --uid 0 --gid 0 --debug-to-files > }}} > > sssd-@respon...@.socket.in: > {{{ > [Unit] > Description=SSSD @responder@ Service responder socket > Documentation=man:sssd.conf(5) > > [Socket] > ListenStream=@pipepath@/@responder@ > > [Install] > WantedBy=sockets.target > }}} > > Some responders may have more than one socket, which is the case of > PAM, so another unit will be needed. > > sssd-@respon...@-priv.socket.in: > {{{ > [Unit] > Description=SSSD @responder@ Service responder private socket > Documentation=man:sssd.conf(5) > > [Socket] > ListenStream=@pipepath@/private/@responder@ > > [Install] > WantedBy=sockets.target > }}} > > Last but not least, the IFP responder doesn't have a socket. It's > going to be D-Bus activated and some small changes will be required on > its D-Bus service unit. > {{{ > -Exec=@libexecdir@/sssd/sss_signal > +Exec=@libexecdir@/sssd/sssd_@responder@ > }}} > > And, finally, the code in the monitor side will have to have some > adjustments in order to properly deal with an empty list of services > and, also, to register the service when it's started. > > As just the responders' will be socket-activated for now, the service > type will have to exposed and passed through sbus when calling the > RegistrationService method and the monitor will have to properly do > the registration of the service when Registrat