On (09/01/17 11:35), Fabiano FidĂȘncio wrote:
On Mon, Jan 9, 2017 at 11:23 AM, Lukas Slebodnik
<lslebodn(a)redhat.com> 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