[SSSD] Re: RFC: Socket-activation, some changes in the architecture.
On (08/01/17 21:44), Fabiano Fidêncio wrote: >People, > >Recently I've faced some issues when testing the socket-activation >working running as sssd-user, which will force me to take a different >path for a few things and I really would like to know your opinion on >those things. > >So, currently, this is what the nss.service looks like: > >[Unit] >Description=SSSD NSS Service responder >Documentation=man:sssd.conf(5) >After=sssd.service >BindsTo=sssd.service > >[Install] >Also=sssd-nss.socket > >[Service] >ExecStartPre=-/bin/chown @SSSD_USER@:@SSSD_USER@ @logpath@/sssd_nss.log >ExecStart=@libexecdir@/sssd/sssd_nss --debug-to-files --unprivileged-start >Restart=on-failure >User=@SSSD_USER@ >Group=@SSSD_USER@ >PermissionsStartOnly=true > >As you probably noticed, I've been using systemd's machinery to change >the debug files' owner and to start the responder by the proper user >(sssd or root). Well, it doesn't work that well as expected as systemd >ends up calling initgroups(sssd, ...) in order to start any service >using "sssd" user and this call is done _before_ starting the NSS >responder, which will hang for the "default client timeout" (300s). > It is not just about initgroups(). I checked the source code and it also calls getpwname get grname for User/GID !=0 and Group/GID !=0. It is not a problem ATM but it would be problem after changing nsswitch "passwd: files sss" -> "passwd: sss files" Yes; we can remove this options from nss service file; but there still will be a chown in ExecStartPre; which will cause problems after changing nsswitch configuration. It would not be a problem with "chown $uid:$gid" but these values are not constant. And we need to change owner of the log file otherwise we would not be able to start responder after upgrade from root user without socket activation -> non-root user with socket activation. We cannot translate sssd user to uid/gid at build time because values would be different on build machine (chroot ...) and on installed machine. I think the only reasonable solution for non-root mode and nss responder would be to provide drop-in file with uid/gid in /etc/systemd/system The same as for logging to journald /etc/systemd/system/sssd.service.d/journal.conf We can replace values in rpm posinstall scriptlet and enable it by default. Other distributions might do the same or they can rely on manual change. That will be a downstream packager decision. LS ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: RFC: Socket-activation, some changes in the architecture.
On Mon, Jan 9, 2017 at 10:27 AM, Lukas Slebodnik wrote: > On (08/01/17 21:44), Fabiano Fidêncio wrote: >>People, >> >>Recently I've faced some issues when testing the socket-activation >>working running as sssd-user, which will force me to take a different >>path for a few things and I really would like to know your opinion on >>those things. >> >>So, currently, this is what the nss.service looks like: >> >>[Unit] >>Description=SSSD NSS Service responder >>Documentation=man:sssd.conf(5) >>After=sssd.service >>BindsTo=sssd.service >> >>[Install] >>Also=sssd-nss.socket >> >>[Service] >>ExecStartPre=-/bin/chown @SSSD_USER@:@SSSD_USER@ @logpath@/sssd_nss.log >>ExecStart=@libexecdir@/sssd/sssd_nss --debug-to-files --unprivileged-start >>Restart=on-failure >>User=@SSSD_USER@ >>Group=@SSSD_USER@ >>PermissionsStartOnly=true >> >>As you probably noticed, I've been using systemd's machinery to change >>the debug files' owner and to start the responder by the proper user >>(sssd or root). Well, it doesn't work that well as expected as systemd >>ends up calling initgroups(sssd, ...) in order to start any service >>using "sssd" user and this call is done _before_ starting the NSS >>responder, which will hang for the "default client timeout" (300s). >> > It is not just about initgroups(). I checked the source code and > it also calls getpwname get grname for User/GID !=0 and Group/GID !=0. > It is not a problem ATM but it would be problem after changing nsswitch > "passwd: files sss" -> "passwd: sss files" > > Yes; we can remove this options from nss service file; but there > still will be a chown in ExecStartPre; which will cause problems > after changing nsswitch configuration. It would not be a problem > with "chown $uid:$gid" but these values are not constant. Sorry, maybe I was not clear enough when writing the email. My proposal is to have --sssd-user=@SSSD_USER@ passed as a command line argument to the responder. So, exactly as it's done nowadays, we would be able to own the debug files and become the user without any issue (with the patches I've described in the email). > And we need to change owner of the log file otherwise we would > not be able to start responder after upgrade from root user without > socket activation -> non-root user with socket activation. Answered above. > > We cannot translate sssd user to uid/gid at build time > because values would be different on build machine (chroot ...) > and on installed machine. Answered above. > > I think the only reasonable solution for non-root mode and nss responder > would be to provide drop-in file with uid/gid in /etc/systemd/system I wrote the email giving another reasonable solution for non-root mode. :-\ > > The same as for logging to journald > /etc/systemd/system/sssd.service.d/journal.conf > We can replace values in rpm posinstall scriptlet and enable it by default. > Other distributions might do the same or they can rely on manual change. > That will be a downstream packager decision. > > LS > ___ > sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org > To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org 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: RFC: Socket-activation, some changes in the architecture.
On (09/01/17 10:43), Fabiano Fidêncio wrote: >On Mon, Jan 9, 2017 at 10:27 AM, Lukas Slebodnik wrote: >> On (08/01/17 21:44), Fabiano Fidêncio wrote: >>>People, >>> >>>Recently I've faced some issues when testing the socket-activation >>>working running as sssd-user, which will force me to take a different >>>path for a few things and I really would like to know your opinion on >>>those things. >>> >>>So, currently, this is what the nss.service looks like: >>> >>>[Unit] >>>Description=SSSD NSS Service responder >>>Documentation=man:sssd.conf(5) >>>After=sssd.service >>>BindsTo=sssd.service >>> >>>[Install] >>>Also=sssd-nss.socket >>> >>>[Service] >>>ExecStartPre=-/bin/chown @SSSD_USER@:@SSSD_USER@ @logpath@/sssd_nss.log >>>ExecStart=@libexecdir@/sssd/sssd_nss --debug-to-files --unprivileged-start >>>Restart=on-failure >>>User=@SSSD_USER@ >>>Group=@SSSD_USER@ >>>PermissionsStartOnly=true >>> >>>As you probably noticed, I've been using systemd's machinery to change >>>the debug files' owner and to start the responder by the proper user >>>(sssd or root). Well, it doesn't work that well as expected as systemd >>>ends up calling initgroups(sssd, ...) in order to start any service >>>using "sssd" user and this call is done _before_ starting the NSS >>>responder, which will hang for the "default client timeout" (300s). >>> >> It is not just about initgroups(). I checked the source code and >> it also calls getpwname get grname for User/GID !=0 and Group/GID !=0. >> It is not a problem ATM but it would be problem after changing nsswitch >> "passwd: files sss" -> "passwd: sss files" >> >> Yes; we can remove this options from nss service file; but there >> still will be a chown in ExecStartPre; which will cause problems >> after changing nsswitch configuration. It would not be a problem >> with "chown $uid:$gid" but these values are not constant. > >Sorry, maybe I was not clear enough when writing the email. >My proposal is to have --sssd-user=@SSSD_USER@ passed as a command >line argument to the responder. >So, exactly as it's done nowadays, we would be able to own the debug >files and become the user without any issue (with the patches I've >described in the email). > >> And we need to change owner of the log file otherwise we would >> not be able to start responder after upgrade from root user without >> socket activation -> non-root user with socket activation. > >Answered above. > >> >> We cannot translate sssd user to uid/gid at build time >> because values would be different on build machine (chroot ...) >> and on installed machine. > >Answered above. > >> >> I think the only reasonable solution for non-root mode and nss responder >> would be to provide drop-in file with uid/gid in /etc/systemd/system > >I wrote the email giving another reasonable solution for non-root mode. :-\ > I let decide others what is more reasonable and simpler. LS ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: RFC: Socket-activation, some changes in the architecture.
On (08/01/17 21:44), Fabiano Fidêncio wrote:
>diff --git a/src/util/server.c b/src/util/server.c
>index c9a2726..d9da803 100644
>--- a/src/util/server.c
>+++ b/src/util/server.c
>@@ -445,6 +445,7 @@ static const char *get_pid_path(void)
>
> int server_setup(const char *name, int flags,
> uid_t uid, gid_t gid,
>+ char *sssd_user,
> const char *conf_entry,
> struct main_context **main_ctx)
> {
>@@ -463,6 +464,22 @@ int server_setup(const char *name, int flags,
>
> setenv("_SSS_LOOPS", "NO", 0);
>
>+if (sssd_user != NULL) {
>+struct passwd *pw;
>+
>+pw = getpwnam(sssd_user);
>+if (pw == NULL) {
>+DEBUG(SSSDBG_MINOR_FAILURE,
>+ "Cannot get the information about the user %s. "
>+ "The process will be run as root\n", sssd_user);
BTW We should not fall back to root.
User might expect that service will be running as non-root
and due to typo it will fall back to root. They needn't notice it.
>+uid = 0;
>+gid = 0;
>+} else {
>+uid = pw->pw_uid;
>+gid = pw->pw_gid;
>+}
>+}
>+
> ret = chown_debug_file(NULL, uid, gid);
>
>Okay, okay. It would work. Would it be okay for the rest of the developers?
>
//snip
>So, summing up the questions ...
>- Is there any problem on calling 'setenv("_SSS_LOOPS", "NO", 0)'
>earlier in the process?
>- Would be okay adding "--sssd-user" option for starting the responders?
This option is required just for nss responder due to circular dependency
with socket activation. Does it worth to add it to each service?
Because other services can be easily handled by systemd non-root solution
without any problem.
>- Shall I get rid of the "--uid and --gid" options in order to only
>use the new added "--sssd-user" one?
>- Shall I add a new "--socket-activated" option for starting the
>responders or just abuse the "--sssd-user" one?
-1 for misusing other options.
If others developers prefer replacing --uid/gid with "--sssd-user"
then we would not be able to distinguish between socket activated
non-root and sssd monitor version of non-root. And we still need to
be able to handle current solution due backward compatibility.
LS
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: RFC: Socket-activation, some changes in the architecture.
On Mon, Jan 9, 2017 at 11:23 AM, Lukas Slebodnik wrote:
> On (08/01/17 21:44), Fabiano Fidêncio wrote:
>>diff --git a/src/util/server.c b/src/util/server.c
>>index c9a2726..d9da803 100644
>>--- a/src/util/server.c
>>+++ b/src/util/server.c
>>@@ -445,6 +445,7 @@ static const char *get_pid_path(void)
>>
>> int server_setup(const char *name, int flags,
>> uid_t uid, gid_t gid,
>>+ char *sssd_user,
>> const char *conf_entry,
>> struct main_context **main_ctx)
>> {
>>@@ -463,6 +464,22 @@ int server_setup(const char *name, int flags,
>>
>> setenv("_SSS_LOOPS", "NO", 0);
>>
>>+if (sssd_user != NULL) {
>>+struct passwd *pw;
>>+
>>+pw = getpwnam(sssd_user);
>>+if (pw == NULL) {
>>+DEBUG(SSSDBG_MINOR_FAILURE,
>>+ "Cannot get the information about the user %s. "
>>+ "The process will be run as root\n", sssd_user);
> BTW We should not fall back to root.
> User might expect that service will be running as non-root
> and due to typo it will fall back to root. They needn't notice it.
Okay, so aborting is the best thing to do?
I'm okay with that as well.
>>+uid = 0;
>>+gid = 0;
>>+} else {
>>+uid = pw->pw_uid;
>>+gid = pw->pw_gid;
>>+}
>>+}
>>+
>> ret = chown_debug_file(NULL, uid, gid);
>>
>>Okay, okay. It would work. Would it be okay for the rest of the developers?
>>
> //snip
>>So, summing up the questions ...
>>- Is there any problem on calling 'setenv("_SSS_LOOPS", "NO", 0)'
>>earlier in the process?
>>- Would be okay adding "--sssd-user" option for starting the responders?
> This option is required just for nss responder due to circular dependency
> with socket activation. Does it worth to add it to each service?
> Because other services can be easily handled by systemd non-root solution
> without any problem.
Yeah, they can, but then, IMO, it won't be consistent (considering
that we can have something a bt more consistent, I'd go for it).
>
>>- Shall I get rid of the "--uid and --gid" options in order to only
>>use the new added "--sssd-user" one?
>
>
>>- Shall I add a new "--socket-activated" option for starting the
>>responders or just abuse the "--sssd-user" one?
> -1 for misusing other options
I completely agree here. So "--socket-activated" may be a good way to go.
.
>
> If others developers prefer replacing --uid/gid with "--sssd-user"
> then we would not be able to distinguish between socket activated
> non-root and sssd monitor version of non-root.
Well. that's not true for two reasons:
- Currently we don't distinguish those and I don't see why we should.
By the code path taken in the monitor side it knows whether the
process is socket-activated or not and, actually, let the service know
whether it was socket-activated or not.
- Adding "---socket-activated" option would makes things simpler and
let me remove the patch where the monitor lets the responders know
whether they were socket-activated or not.
> And we still need to
> be able to handle current solution due backward compatibility.
Please, I don't completely understand here.
Which backward compatibility problem you see? Could you be a bit more verbose?
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: RFC: Socket-activation, some changes in the architecture.
On (09/01/17 11:35), Fabiano Fidêncio wrote:
>On Mon, Jan 9, 2017 at 11:23 AM, Lukas Slebodnik wrote:
>> On (08/01/17 21:44), Fabiano Fidêncio wrote:
>>>So, summing up the questions ...
>>>- Is there any problem on calling 'setenv("_SSS_LOOPS", "NO", 0)'
>>>earlier in the process?
>>>- Would be okay adding "--sssd-user" option for starting the responders?
>> This option is required just for nss responder due to circular dependency
>> with socket activation. Does it worth to add it to each service?
>> Because other services can be easily handled by systemd non-root solution
>> without any problem.
>
>Yeah, they can, but then, IMO, it won't be consistent (considering
>that we can have something a bt more consistent, I'd go for it).
>
Why do we need to be more consistent if nss-responder is a special case?
nss responder cannot use systemd non-root feature.
Other responders can leverage systemd non-root feature and therefore
does not reauire any new parameter for non-root.
BTW I still think that running nss responder as root might be the simplest
solution for the begining. We might use hit other problems in productions
with socket activated responder. We needn't complicate it with non-root
default mode.
>>
>>>- Shall I get rid of the "--uid and --gid" options in order to only
>>>use the new added "--sssd-user" one?
>>
>>
>>>- Shall I add a new "--socket-activated" option for starting the
>>>responders or just abuse the "--sssd-user" one?
>> -1 for misusing other options
>
>I completely agree here. So "--socket-activated" may be a good way to go.
>.
>>
>> If others developers prefer replacing --uid/gid with "--sssd-user"
>> then we would not be able to distinguish between socket activated
>> non-root and sssd monitor version of non-root.
>
>Well. that's not true for two reasons:
>- Currently we don't distinguish those and I don't see why we should.
>By the code path taken in the monitor side it knows whether the
>process is socket-activated or not and, actually, let the service know
>whether it was socket-activated or not.
>- Adding "---socket-activated" option would makes things simpler and
>let me remove the patch where the monitor lets the responders know
>whether they were socket-activated or not.
>
>> And we still need to
>> be able to handle current solution due backward compatibility.
>
>Please, I don't completely understand here.
>Which backward compatibility problem you see? Could you be a bit more verbose?
>
Everything from "-1 for misusing other options" was meant as a comment
for abusing other non-related option for distinguish between socket
activation.
And regarding --socket-activated; maybe it would be better if you could
describe a purpose of the option in details. What will be a difference in
behaviour between sssd compiled with systemd and disabled/enabled option.
ATM I can think just about skipping chown_debug_file in responders with
systemd-non-root. +1 for explicit option
You might have more use-cases which can be/are already mentioned
in desing page.
LS
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: RFC: Socket-activation, some changes in the architecture.
On 01/08/2017 09:44 PM, Fabiano Fidêncio wrote: People, Recently I've faced some issues when testing the socket-activation working running as sssd-user, which will force me to take a different path for a few things and I really would like to know your opinion on those things. So, currently, this is what the nss.service looks like: [Unit] Description=SSSD NSS Service responder Documentation=man:sssd.conf(5) After=sssd.service BindsTo=sssd.service [Install] Also=sssd-nss.socket [Service] ExecStartPre=-/bin/chown @SSSD_USER@:@SSSD_USER@ @logpath@/sssd_nss.log ExecStart=@libexecdir@/sssd/sssd_nss --debug-to-files --unprivileged-start Restart=on-failure User=@SSSD_USER@ Group=@SSSD_USER@ PermissionsStartOnly=true As you probably noticed, I've been using systemd's machinery to change the debug files' owner and to start the responder by the proper user (sssd or root). Well, it doesn't work that well as expected as systemd ends up calling initgroups(sssd, ...) in order to start any service using "sssd" user and this call is done _before_ starting the NSS responder, which will hang for the "default client timeout" (300s). Okay, we have to change it and here is where I need your help! The simplest solution would be to disable socket activation for NSS responder. Socket activation is supposed to be used for responders that are seldom used. ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: RFC: Socket-activation, some changes in the architecture.
On Mon, Jan 09, 2017 at 01:25:48PM +0100, Pavel Březina wrote: > On 01/08/2017 09:44 PM, Fabiano Fidêncio wrote: > > People, > > > > Recently I've faced some issues when testing the socket-activation > > working running as sssd-user, which will force me to take a different > > path for a few things and I really would like to know your opinion on > > those things. > > > > So, currently, this is what the nss.service looks like: > > > > [Unit] > > Description=SSSD NSS Service responder > > Documentation=man:sssd.conf(5) > > After=sssd.service > > BindsTo=sssd.service > > > > [Install] > > Also=sssd-nss.socket > > > > [Service] > > ExecStartPre=-/bin/chown @SSSD_USER@:@SSSD_USER@ @logpath@/sssd_nss.log > > ExecStart=@libexecdir@/sssd/sssd_nss --debug-to-files --unprivileged-start > > Restart=on-failure > > User=@SSSD_USER@ > > Group=@SSSD_USER@ > > PermissionsStartOnly=true > > > > As you probably noticed, I've been using systemd's machinery to change > > the debug files' owner and to start the responder by the proper user > > (sssd or root). Well, it doesn't work that well as expected as systemd > > ends up calling initgroups(sssd, ...) in order to start any service > > using "sssd" user and this call is done _before_ starting the NSS > > responder, which will hang for the "default client timeout" (300s). > > > > Okay, we have to change it and here is where I need your help! > > The simplest solution would be to disable socket activation for NSS > responder. Socket activation is supposed to be used for responders that are > seldom used. I also wonder if this was the easiest. Just enable the service as well in the RPM.. ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: RFC: Socket-activation, some changes in the architecture.
On Mon, Jan 9, 2017 at 1:35 PM, Jakub Hrozek wrote: > On Mon, Jan 09, 2017 at 01:25:48PM +0100, Pavel Březina wrote: >> On 01/08/2017 09:44 PM, Fabiano Fidêncio wrote: >> > People, >> > >> > Recently I've faced some issues when testing the socket-activation >> > working running as sssd-user, which will force me to take a different >> > path for a few things and I really would like to know your opinion on >> > those things. >> > >> > So, currently, this is what the nss.service looks like: >> > >> > [Unit] >> > Description=SSSD NSS Service responder >> > Documentation=man:sssd.conf(5) >> > After=sssd.service >> > BindsTo=sssd.service >> > >> > [Install] >> > Also=sssd-nss.socket >> > >> > [Service] >> > ExecStartPre=-/bin/chown @SSSD_USER@:@SSSD_USER@ @logpath@/sssd_nss.log >> > ExecStart=@libexecdir@/sssd/sssd_nss --debug-to-files --unprivileged-start >> > Restart=on-failure >> > User=@SSSD_USER@ >> > Group=@SSSD_USER@ >> > PermissionsStartOnly=true >> > >> > As you probably noticed, I've been using systemd's machinery to change >> > the debug files' owner and to start the responder by the proper user >> > (sssd or root). Well, it doesn't work that well as expected as systemd >> > ends up calling initgroups(sssd, ...) in order to start any service >> > using "sssd" user and this call is done _before_ starting the NSS >> > responder, which will hang for the "default client timeout" (300s). >> > >> > Okay, we have to change it and here is where I need your help! >> >> The simplest solution would be to disable socket activation for NSS >> responder. Socket activation is supposed to be used for responders that are >> seldom used. > > I also wonder if this was the easiest. Just enable the service as well > in the RPM.. And it still would have to be running as root. Latest suggestion from Lukáš makes my life way easier (just leave this reponder to be ran as root and that's it). Although, I really think we could do it in a better and more generic way 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: RFC: Socket-activation, some changes in the architecture.
On 01/09/2017 01:38 PM, Fabiano Fidêncio wrote: On Mon, Jan 9, 2017 at 1:35 PM, Jakub Hrozek wrote: On Mon, Jan 09, 2017 at 01:25:48PM +0100, Pavel Březina wrote: On 01/08/2017 09:44 PM, Fabiano Fidêncio wrote: People, Recently I've faced some issues when testing the socket-activation working running as sssd-user, which will force me to take a different path for a few things and I really would like to know your opinion on those things. So, currently, this is what the nss.service looks like: [Unit] Description=SSSD NSS Service responder Documentation=man:sssd.conf(5) After=sssd.service BindsTo=sssd.service [Install] Also=sssd-nss.socket [Service] ExecStartPre=-/bin/chown @SSSD_USER@:@SSSD_USER@ @logpath@/sssd_nss.log ExecStart=@libexecdir@/sssd/sssd_nss --debug-to-files --unprivileged-start Restart=on-failure User=@SSSD_USER@ Group=@SSSD_USER@ PermissionsStartOnly=true As you probably noticed, I've been using systemd's machinery to change the debug files' owner and to start the responder by the proper user (sssd or root). Well, it doesn't work that well as expected as systemd ends up calling initgroups(sssd, ...) in order to start any service using "sssd" user and this call is done _before_ starting the NSS responder, which will hang for the "default client timeout" (300s). Okay, we have to change it and here is where I need your help! The simplest solution would be to disable socket activation for NSS responder. Socket activation is supposed to be used for responders that are seldom used. I also wonder if this was the easiest. Just enable the service as well in the RPM.. And it still would have to be running as root. Latest suggestion from Lukáš makes my life way easier (just leave this reponder to be ran as root and that's it). Although, I really think we could do it in a better and more generic way Or we can somehow indicate to sssd client that the nss responder is not started yet and return that sssd does not known this user in this case. 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: RFC: Socket-activation, some changes in the architecture.
On Mon, 2017-01-09 at 13:35 +0100, Jakub Hrozek wrote: > On Mon, Jan 09, 2017 at 01:25:48PM +0100, Pavel Březina wrote: > > On 01/08/2017 09:44 PM, Fabiano Fidêncio wrote: > > > People, > > > > > > Recently I've faced some issues when testing the socket-activation > > > working running as sssd-user, which will force me to take a different > > > path for a few things and I really would like to know your opinion on > > > those things. > > > > > > So, currently, this is what the nss.service looks like: > > > > > > [Unit] > > > Description=SSSD NSS Service responder > > > Documentation=man:sssd.conf(5) > > > After=sssd.service > > > BindsTo=sssd.service > > > > > > [Install] > > > Also=sssd-nss.socket > > > > > > [Service] > > > ExecStartPre=-/bin/chown @SSSD_USER@:@SSSD_USER@ @logpath@/sssd_nss.log > > > ExecStart=@libexecdir@/sssd/sssd_nss --debug-to-files --unprivileged-start > > > Restart=on-failure > > > User=@SSSD_USER@ > > > Group=@SSSD_USER@ > > > PermissionsStartOnly=true > > > > > > As you probably noticed, I've been using systemd's machinery to change > > > the debug files' owner and to start the responder by the proper user > > > (sssd or root). Well, it doesn't work that well as expected as systemd > > > ends up calling initgroups(sssd, ...) in order to start any service > > > using "sssd" user and this call is done _before_ starting the NSS > > > responder, which will hang for the "default client timeout" (300s). > > > > > > Okay, we have to change it and here is where I need your help! > > > > The simplest solution would be to disable socket activation for NSS > > responder. Socket activation is supposed to be used for responders that are > > seldom used. > > I also wonder if this was the easiest. Just enable the service as well > in the RPM.. Once we start handling local users (and we want to do that by default) we'll have to always run as root anyway, so what's the point of dealing with changing the user ? 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: RFC: Socket-activation, some changes in the architecture.
On (09/01/17 09:43), Simo Sorce wrote: >On Mon, 2017-01-09 at 13:35 +0100, Jakub Hrozek wrote: >> On Mon, Jan 09, 2017 at 01:25:48PM +0100, Pavel Březina wrote: >> > On 01/08/2017 09:44 PM, Fabiano Fidêncio wrote: >> > > People, >> > > >> > > Recently I've faced some issues when testing the socket-activation >> > > working running as sssd-user, which will force me to take a different >> > > path for a few things and I really would like to know your opinion on >> > > those things. >> > > >> > > So, currently, this is what the nss.service looks like: >> > > >> > > [Unit] >> > > Description=SSSD NSS Service responder >> > > Documentation=man:sssd.conf(5) >> > > After=sssd.service >> > > BindsTo=sssd.service >> > > >> > > [Install] >> > > Also=sssd-nss.socket >> > > >> > > [Service] >> > > ExecStartPre=-/bin/chown @SSSD_USER@:@SSSD_USER@ @logpath@/sssd_nss.log >> > > ExecStart=@libexecdir@/sssd/sssd_nss --debug-to-files >> > > --unprivileged-start >> > > Restart=on-failure >> > > User=@SSSD_USER@ >> > > Group=@SSSD_USER@ >> > > PermissionsStartOnly=true >> > > >> > > As you probably noticed, I've been using systemd's machinery to change >> > > the debug files' owner and to start the responder by the proper user >> > > (sssd or root). Well, it doesn't work that well as expected as systemd >> > > ends up calling initgroups(sssd, ...) in order to start any service >> > > using "sssd" user and this call is done _before_ starting the NSS >> > > responder, which will hang for the "default client timeout" (300s). >> > > >> > > Okay, we have to change it and here is where I need your help! >> > >> > The simplest solution would be to disable socket activation for NSS >> > responder. Socket activation is supposed to be used for responders that are >> > seldom used. >> >> I also wonder if this was the easiest. Just enable the service as well >> in the RPM.. > >Once we start handling local users (and we want to do that by default) >we'll have to always run as root anyway, so what's the point of dealing >with changing the user ? > Could you say the reason why we *have to* run as root? LS ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
