[SSSD] Re: Design document - Socket-activatable responders

2016-12-02 Thread Pavel Březina 

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

2016-12-01 Thread Jakub Hrozek 
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

2016-12-01 Thread Fabiano Fidêncio 
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

2016-12-01 Thread Simo Sorce 
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

2016-12-01 Thread Simo Sorce 
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

2016-12-01 Thread Pavel Březina 

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

2016-12-01 Thread Fabiano Fidêncio 
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

2016-12-01 Thread Simo Sorce 
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

2016-12-01 Thread Pavel Březina 

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

2016-11-30 Thread Pavel Březina 

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 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, _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

2016-11-29 Thread Jakub Hrozek 
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 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, _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

2016-11-29 Thread Lukas Slebodnik 
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 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, _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

2016-11-29 Thread Fabiano Fidêncio 
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 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

2016-11-29 Thread Jakub Hrozek 
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 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

2016-11-29 Thread Lukas Slebodnik 
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 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

2016-11-29 Thread Fabiano Fidêncio 
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 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

2016-11-29 Thread Sumit Bose 
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 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

2016-11-29 Thread Jakub Hrozek 
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 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

2016-11-29 Thread Lukas Slebodnik 
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 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

2016-11-29 Thread Lukas Slebodnik 
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 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

2016-11-29 Thread Jakub Hrozek 
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 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

2016-11-29 Thread Jakub Hrozek 
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 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

2016-11-29 Thread Fabiano Fidêncio 
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 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

2016-11-29 Thread Lukas Slebodnik 
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 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

2016-11-29 Thread Lukas Slebodnik 
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 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

2016-11-28 Thread Jakub Hrozek 
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 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

2016-11-28 Thread Pavel Březina 

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 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

2016-11-28 Thread Jakub Hrozek 
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 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

2016-11-24 Thread amit kumar 
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 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

[SSSD] Re: Design document - Socket-activatable responders

2016-11-24 Thread Fabiano Fidêncio 
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 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