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.o... [2]: https://github.com/SSSD/sssd/pull/84
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-@responder@.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-@responder@.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-@responder@-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 RegistrationService's callback is triggered. As mentioned before, the "registration" that has to be done from the monitor's side is: * Mark the service as started; * Increase the services' counter; * Get the responders' configuration; * Set the service's restart number; * Add the service to the services' list.
=== Configuration changes === After this design is implemented, the "services" line in sssd.conf will become optional for platforms where systemd is present. Note that in order to keep backward compatibility, if the "services" line is present, the services will behave exactly as they did before these changes.
=== How To Test === The easiest way to test is removing the "services" line from sssd.conf and try to use SSSD normally. Using sssctl tool without having the ifp responder set in the "services" line is another way to test.
=== How To Debug === The easiest way to debug this new feature is taking a look on the responders' common initialization code and in the monitors' client registration code. Is worth to mention that disabling the systemd's services/sockets will prevent the responders' services to be started.
=== Authors === Fabiano Fidêncio fidencio@redhat.com
Best Regards, -- Fabiano Fidêncio
On Thu, Nov 24, 2016 at 2:33 PM, Fabiano Fidêncio fidencio@redhat.com 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].
Well, PR#94: https://github.com/SSSD/sssd/pull/94
The full text of c&p here:
= Socket Activatable Responders =
Related ticket(s):
=== 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-@responder@.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-@responder@.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-@responder@-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 RegistrationService's callback is triggered. As mentioned before, the "registration" that has to be done from the monitor's side is:
- Mark the service as started;
- Increase the services' counter;
- Get the responders' configuration;
- Set the service's restart number;
- Add the service to the services' list.
=== Configuration changes === After this design is implemented, the "services" line in sssd.conf will become optional for platforms where systemd is present. Note that in order to keep backward compatibility, if the "services" line is present, the services will behave exactly as they did before these changes.
=== How To Test === The easiest way to test is removing the "services" line from sssd.conf and try to use SSSD normally. Using sssctl tool without having the ifp responder set in the "services" line is another way to test.
=== How To Debug === The easiest way to debug this new feature is taking a look on the responders' common initialization code and in the monitors' client registration code. Is worth to mention that disabling the systemd's services/sockets will prevent the responders' services to be started.
=== Authors === Fabiano Fidêncio fidencio@redhat.com
Best Regards,
Fabiano Fidêncio _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-leave@lists.fedorahosted.org
Best Regards,
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 fidencio@redhat.com 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].
Well, PR#94: https://github.com/SSSD/sssd/pull/94
The full text of c&p here:
= Socket Activatable Responders =
Related ticket(s):
=== 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-@responder@.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-@responder@.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-@responder@-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 RegistrationService's callback is triggered. As mentioned before, the "registration" that has to be done from the monitor's side is:
- Mark the service as started;
- Increase the services' counter;
- Get the responders' configuration;
- Set the service's restart number;
- Add the service to the services' list.
=== Configuration changes === After this design is implemented, the "services" line in sssd.conf will become optional for platforms where systemd is present. Note that in order to keep backward compatibility, if the "services" line is present, the services will behave exactly as they did before these changes.
=== How To Test === The easiest way to test is removing the "services" line from sssd.conf and try to use SSSD normally. Using sssctl tool without having the ifp responder set in the "services" line is another way to test.
=== How To Debug === The easiest way to debug this new feature is taking a look on the responders' common initialization code and in the monitors' client registration code. Is worth to mention that disabling the systemd's services/sockets will prevent the responders' services to be started.
=== Authors === Fabiano Fidêncio fidencio@redhat.com
Best Regards,
Fabiano Fidêncio _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-leave@lists.fedorahosted.org
Best Regards,
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].
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):
=== 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-@responder@.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-@responder@.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-@responder@-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 RegistrationService's callback is triggered. As mentioned before, the "registration" that has to be done from the monitor's side is:
- Mark the service as started;
- Increase the services' counter;
- Get the responders' configuration;
- Set the service's restart number;
- Add the service to the services' list.
=== Configuration changes === After this design is implemented, the "services" line in sssd.conf will become optional for platforms where systemd is present. Note that in order to keep backward compatibility, if the "services" line is present, the services will behave exactly as they did before these changes.
=== How To Test === The easiest way to test is removing the "services" line from sssd.conf and try to use SSSD normally. Using sssctl tool without having the ifp responder set in the "services" line is another way to test.
=== How To Debug === The easiest way to debug this new feature is taking a look on the responders' common initialization code and in the monitors' client registration code. Is worth to mention that disabling the systemd's services/sockets will prevent the responders' services to be started.
=== Authors === Fabiano Fidêncio fidencio@redhat.com
Best Regards,
Fabiano Fidêncio _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-leave@lists.fedorahosted.org
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].
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.
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].
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-leave@lists.fedorahosted.org
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].
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
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].
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
On Tue, Nov 29, 2016 at 10:01 AM, Lukas Slebodnik lslebodn@redhat.com 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].
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
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 lslebodn@redhat.com 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].
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?
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 lslebodn@redhat.com 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.o... > [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.
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
On Tue, Nov 29, 2016 at 10:24 AM, Fabiano Fidêncio fidencio@redhat.com wrote:
On Tue, Nov 29, 2016 at 10:01 AM, Lukas Slebodnik lslebodn@redhat.com 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].
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
On (29/11/16 12:13), Fabiano Fidêncio wrote:
On Tue, Nov 29, 2016 at 10:24 AM, Fabiano Fidêncio fidencio@redhat.com wrote:
On Tue, Nov 29, 2016 at 10:01 AM, Lukas Slebodnik lslebodn@redhat.com 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.o... > [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
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 fidencio@redhat.com wrote:
On Tue, Nov 29, 2016 at 10:01 AM, Lukas Slebodnik lslebodn@redhat.com 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.o... > > [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-leave@lists.fedorahosted.org
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 fidencio@redhat.com wrote:
On Tue, Nov 29, 2016 at 10:01 AM, Lukas Slebodnik lslebodn@redhat.com 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.o... >>> [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.
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].
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
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].
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
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.o... > [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.
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.o... > > [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
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.o... > > > [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?"
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].
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
On Tue, Nov 29, 2016 at 11:28 AM, Sumit Bose sbose@redhat.com 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].
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,
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].
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.
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].
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.
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].
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.
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].
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.
On Thu, Dec 1, 2016 at 3:46 PM, Simo Sorce simo@redhat.com 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].
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-leave@lists.fedorahosted.org
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 simo@redhat.com 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].
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.
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 simo@redhat.com 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.o... > [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.
On Thu, Dec 1, 2016 at 2:44 PM, Pavel Březina pbrezina@redhat.com 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].
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-leave@lists.fedorahosted.org
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 pbrezina@redhat.com 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].
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.
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 pbrezina@redhat.com 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].
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@lists.fedorahosted.org
-
amit kumar -
Fabiano Fidêncio -
Fabiano Fidêncio -
Jakub Hrozek -
Lukas Slebodnik -
Pavel Březina -
Simo Sorce -
Sumit Bose