authselect: what to do with systemd and nss-mdns that modify nsswith.conf

[Pavel Březina]

Hello,

systemd and nss-mdns packages modifies nsswitch.conf in their %post
scriptlets which creates conflicts with authselect on systems that are
configured by authselect. This needs to be solved somehow.

Originally, I wanted to create an authselect command that can be used by
packages on systems that are configured by authselect and on systems
that are configured with different ways [1]. But it turned out that
there are only two packages that touches nsswitch.conf so I do not think
this is necessary.

I prepared initial design document with multiple solutions that came to
my mind [2] and I would like to discuss this with the community to see
what is the correct and desired way to solve this.

Thank you,
Pavel.

[1]
https://lists.fedoraproject.org/archives/list/***@lists.fedoraproject.org/message/4YMQOZCV32272UIGZM45NVJLVZY2UOZH/

[2]
https://fedoraproject.org/wiki/User:Pbrezina/Authselect_and_packages_that_modifies_nsswitch
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/***@lists.fedoraprojec

[Florian Weimer]

Post by Pavel Březina
systemd and nss-mdns packages modifies nsswitch.conf in their %post
scriptlets which creates conflicts with authselect on systems that are
configured by authselect. This needs to be solved somehow.

Other packagers (notably sssd) have made the required changes by
requesting them form glibc developers.

Would this help to solve the problem here?

Thanks,
Florian
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/***@lists.fedoraproject.org

[Pavel Březina]

Post by Florian Weimer

Post by Pavel Březina
systemd and nss-mdns packages modifies nsswitch.conf in their %post
scriptlets which creates conflicts with authselect on systems that are
configured by authselect. This needs to be solved somehow.

Other packagers (notably sssd) have made the required changes by
requesting them form glibc developers.
Would this help to solve the problem here?

If all those packages should be enabled by default, this probably the
best solution.

Post by Florian Weimer
Thanks,
Florian

_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraprojec

[Lennart Poettering]

Post by Pavel Březina
Hello,

Heya!

Post by Pavel Březina
systemd and nss-mdns packages modifies nsswitch.conf in their %post
scriptlets which creates conflicts with authselect on systems that are
configured by authselect. This needs to be solved somehow.
Originally, I wanted to create an authselect command that can be used by
packages on systems that are configured by authselect and on systems that
are configured with different ways [1]. But it turned out that there are
only two packages that touches nsswitch.conf so I do not think this is
necessary.
I prepared initial design document with multiple solutions that came to my
mind [2] and I would like to discuss this with the community to see what is
the correct and desired way to solve this.

nss-systemd should be in nsswitch.conf by default. It's required for
systemd's DynamicUser=1 option to work correctly, and that's core
service functionality. Hence, given that systemd is Fedora's PID 1,
nss-systemd should also be in nsswitch.conf unconditionally (in the
'passwd' and 'group' lines). A system where nss-systemd is not enabled
is simply broken right now.

nss-myhostname should be in nsswitch.conf by default too. It's very
minimal, and just makes sure the local hostname remains resolvable all
the time. By enabling this, installers and image generators don't have
to patch /etc/hosts anymore like they traditionally did, in fact they
can remove it altogether and just leave resolution of the local
hostname to the module, and it will magically follow whatever is
currently set via sethostname(). This module should be in the 'hosts'
line.

Then there is nss-mymachines. It's primarily useful if
systemd-machined or systemd-nspawn is used. Given that those are now
part of the 'systemd-container' RPM it would be OK to also add
nss-mymachines to nsswitch.conf only when the RPM is installed, if
there's a concept for that. That said, in order to simplify things,
and given that systemd is a very core part of the OS I'd personally
just put it statically in nsswitch.conf too by default. After all a
missing NSS module listed in nsswitch.conf is just skipped, hence this
should not matter. This module should be in the 'passwd', 'group' and
'hosts' lines.

Finally, there's nss-resolve. It's the client side to
systemd-resolved. It's the client side to systemd-resolved's
DNS/mDNS/LLMNR/DoT/DNSSEC stack. systemd-resolved is not default in
Fedora right now. Quite frankly I think it should be, but that's another
political discussion (and I am not sure I am ready to have it right
now). The module is benign though: if resolved is not running it
doesn't do anything. It only does its thing if resolved is
running. Thus I'd also suggest to just enable it by default, and
simplify things because then people can use resolved just by doing
"systemctl enable systemd-resolved" and don't need to do anything
else. This module should be in the 'hosts' line.

Summary: I'd make things simple, and enable all four unconditionally
and by default without any dynamic infrastructure, without postinst
scripts or anything. If that's not acceptable, then at least two of the
four should be unconditionally enabled.

Lennart

[Tom Hughes]

Post by Lennart Poettering
nss-systemd should be in nsswitch.conf by default. It's required for
systemd's DynamicUser=1 option to work correctly, and that's core
service functionality. Hence, given that systemd is Fedora's PID 1,
nss-systemd should also be in nsswitch.conf unconditionally (in the
'passwd' and 'group' lines). A system where nss-systemd is not enabled
is simply broken right now.
nss-myhostname should be in nsswitch.conf by default too. It's very
minimal, and just makes sure the local hostname remains resolvable all
the time. By enabling this, installers and image generators don't have
to patch /etc/hosts anymore like they traditionally did, in fact they
can remove it altogether and just leave resolution of the local
hostname to the module, and it will magically follow whatever is
currently set via sethostname(). This module should be in the 'hosts'
line.

Based on my experimentation with an F29 live image last week both
nss-systemd and nss-myhostname are in the default configuration.

Post by Lennart Poettering
Then there is nss-mymachines. It's primarily useful if
systemd-machined or systemd-nspawn is used. Given that those are now
part of the 'systemd-container' RPM it would be OK to also add
nss-mymachines to nsswitch.conf only when the RPM is installed, if
there's a concept for that. That said, in order to simplify things,
and given that systemd is a very core part of the OS I'd personally
just put it statically in nsswitch.conf too by default. After all a
missing NSS module listed in nsswitch.conf is just skipped, hence this
should not matter. This module should be in the 'passwd', 'group' and
'hosts' lines.
Finally, there's nss-resolve. It's the client side to
systemd-resolved. It's the client side to systemd-resolved's
DNS/mDNS/LLMNR/DoT/DNSSEC stack. systemd-resolved is not default in
Fedora right now. Quite frankly I think it should be, but that's another
political discussion (and I am not sure I am ready to have it right
now). The module is benign though: if resolved is not running it
doesn't do anything. It only does its thing if resolved is
running. Thus I'd also suggest to just enable it by default, and
simplify things because then people can use resolved just by doing
"systemctl enable systemd-resolved" and don't need to do anything
else. This module should be in the 'hosts' line.

Equally, neither nss-mymachines or nss-resolve appear to be in
the default configuration on an F29 image.

Tom

--
Tom Hughes (***@compton.nu)
http://compton.nu/
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/***@lists.fedor

[Florian Weimer]

Post by Tom Hughes
Based on my experimentation with an F29 live image last week both
nss-systemd and nss-myhostname are in the default configuration.

Not in the file shipped by the glibc package.

Florian
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/arc

[Tom Hughes]

Post by Florian Weimer

Post by Tom Hughes
Based on my experimentation with an F29 live image last week both
nss-systemd and nss-myhostname are in the default configuration.

Not in the file shipped by the glibc package.

Well something that has been installed as part of the live
image has enabled them then...

Tom

--
Tom Hughes (***@compton.nu)
http://compton.nu/
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/***@lists.fedor

[Pavel Březina]

Post by Tom Hughes

Post by Florian Weimer

Post by Tom Hughes
Based on my experimentation with an F29 live image last week both
nss-systemd and nss-myhostname are in the default configuration.

Not in the file shipped by the glibc package.

Well something that has been installed as part of the live
image has enabled them then...
Tom

systemd scriptlet enabled them in nsswitch.conf.

Additionally, if you have configured your system with authselect, there
is systemd in all profiles shipped with the package in passwd and
groups. But modules in hosts are still enabled via systemd scriptlet.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproj

[Pavel Březina]

Post by Lennart Poettering

Post by Pavel Březina
Hello,

Heya!

Post by Pavel Březina
systemd and nss-mdns packages modifies nsswitch.conf in their %post
scriptlets which creates conflicts with authselect on systems that are
configured by authselect. This needs to be solved somehow.
Originally, I wanted to create an authselect command that can be used by
packages on systems that are configured by authselect and on systems that
are configured with different ways [1]. But it turned out that there are
only two packages that touches nsswitch.conf so I do not think this is
necessary.
I prepared initial design document with multiple solutions that came to my
mind [2] and I would like to discuss this with the community to see what is
the correct and desired way to solve this.

nss-systemd should be in nsswitch.conf by default. It's required for
systemd's DynamicUser=1 option to work correctly, and that's core
service functionality. Hence, given that systemd is Fedora's PID 1,
nss-systemd should also be in nsswitch.conf unconditionally (in the
'passwd' and 'group' lines). A system where nss-systemd is not enabled
is simply broken right now.
nss-myhostname should be in nsswitch.conf by default too. It's very
minimal, and just makes sure the local hostname remains resolvable all
the time. By enabling this, installers and image generators don't have
to patch /etc/hosts anymore like they traditionally did, in fact they
can remove it altogether and just leave resolution of the local
hostname to the module, and it will magically follow whatever is
currently set via sethostname(). This module should be in the 'hosts'
line.
Then there is nss-mymachines. It's primarily useful if
systemd-machined or systemd-nspawn is used. Given that those are now
part of the 'systemd-container' RPM it would be OK to also add
nss-mymachines to nsswitch.conf only when the RPM is installed, if
there's a concept for that. That said, in order to simplify things,
and given that systemd is a very core part of the OS I'd personally
just put it statically in nsswitch.conf too by default. After all a
missing NSS module listed in nsswitch.conf is just skipped, hence this
should not matter. This module should be in the 'passwd', 'group' and
'hosts' lines.

Reading https://bugzilla.redhat.com/show_bug.cgi?id=1284325 there is can
happen some ID overlaps with FreeIPA/Samba which is undesirable. I would
say that this must be solves if this module is enabled by default. Was
there any progress in this area?

Post by Lennart Poettering
Finally, there's nss-resolve. It's the client side to
systemd-resolved. It's the client side to systemd-resolved's
DNS/mDNS/LLMNR/DoT/DNSSEC stack. systemd-resolved is not default in
Fedora right now. Quite frankly I think it should be, but that's another
political discussion (and I am not sure I am ready to have it right
now). The module is benign though: if resolved is not running it
doesn't do anything. It only does its thing if resolved is
running. Thus I'd also suggest to just enable it by default, and
simplify things because then people can use resolved just by doing
"systemctl enable systemd-resolved" and don't need to do anything
else. This module should be in the 'hosts' line.
Summary: I'd make things simple, and enable all four unconditionally
and by default without any dynamic infrastructure, without postinst
scripts or anything. If that's not acceptable, then at least two of the
four should be unconditionally enabled.
Lennart
--
Lennart Poettering, Red Hat
_______________________________________________
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/***@lists.fe

[Lennart Poettering]

Post by Pavel Březina

Post by Lennart Poettering
Then there is nss-mymachines. It's primarily useful if
systemd-machined or systemd-nspawn is used. Given that those are now
part of the 'systemd-container' RPM it would be OK to also add
nss-mymachines to nsswitch.conf only when the RPM is installed, if
there's a concept for that. That said, in order to simplify things,
and given that systemd is a very core part of the OS I'd personally
just put it statically in nsswitch.conf too by default. After all a
missing NSS module listed in nsswitch.conf is just skipped, hence this
should not matter. This module should be in the 'passwd', 'group' and
'hosts' lines.

Reading https://bugzilla.redhat.com/show_bug.cgi?id=1284325 there is can
happen some ID overlaps with FreeIPA/Samba which is undesirable. I would say
that this must be solves if this module is enabled by default. Was there any
progress in this area?

I think that's a misunderstanding of what the module does. At the
point the module announces those uid/gid ranges they are already
reserved, hence the conflict is already there. nss-mymachines is hence
only the messanger, not the culprit. Moreover, I think that
registering all taken users in NSS is really key to minimize such
conflicts. Hence, I am very strongly of the opinion that any component
taking possession off a user or a range of users it *must* show up in
NSS too, so that other components know.

I commented on the bug too.

Lennart

[Florian Weimer]

Post by Lennart Poettering

Post by Pavel Březina

Post by Lennart Poettering
Then there is nss-mymachines. It's primarily useful if
systemd-machined or systemd-nspawn is used. Given that those are now
part of the 'systemd-container' RPM it would be OK to also add
nss-mymachines to nsswitch.conf only when the RPM is installed, if
there's a concept for that. That said, in order to simplify things,
and given that systemd is a very core part of the OS I'd personally
just put it statically in nsswitch.conf too by default. After all a
missing NSS module listed in nsswitch.conf is just skipped, hence this
should not matter. This module should be in the 'passwd', 'group' and
'hosts' lines.

Reading https://bugzilla.redhat.com/show_bug.cgi?id=1284325 there is can
happen some ID overlaps with FreeIPA/Samba which is undesirable. I would say
that this must be solves if this module is enabled by default. Was there any
progress in this area?

I think that's a misunderstanding of what the module does. At the
point the module announces those uid/gid ranges they are already
reserved, hence the conflict is already there. nss-mymachines is hence
only the messanger, not the culprit.

I don't think we enforce that reservation system-wide. Do we filter out
those accounts when they come in over LDAP? Can users add them locally
using adduser?

None of the NSS modules in glibc provide such filtering.

Thanks,
Florian
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedor

[Lennart Poettering]

Post by Florian Weimer

Post by Lennart Poettering

Post by Pavel Březina
Reading https://bugzilla.redhat.com/show_bug.cgi?id=1284325 there is can
happen some ID overlaps with FreeIPA/Samba which is undesirable. I would say
that this must be solves if this module is enabled by default. Was there any
progress in this area?

I think that's a misunderstanding of what the module does. At the
point the module announces those uid/gid ranges they are already
reserved, hence the conflict is already there. nss-mymachines is hence
only the messanger, not the culprit.

I don't think we enforce that reservation system-wide. Do we filter out
those accounts when they come in over LDAP? Can users add them locally
using adduser?
None of the NSS modules in glibc provide such filtering.

The UID/GID allocation in systemd itself (for DynamicUser=1) and in
systemd-nspawn (for --private-users=) both check NSS before they take
a UID/GID. Hence, if LDAP users live in the same range we use it makes
the space scarcer, but it shouldn't cause conflicts — as long as
everything is properly registered in NSS.

"adduser" registers from the range 1000…60000 on Fedora by
default. DynamicUser=1 uses the range 61184…65519. systemd-nspawn uses
524288…1879048191. So these at least do not overlap.

Lennart

[Florian Weimer]

Post by Lennart Poettering
nss-myhostname should be in nsswitch.conf by default too. It's very
minimal, and just makes sure the local hostname remains resolvable all
the time. By enabling this, installers and image generators don't have
to patch /etc/hosts anymore like they traditionally did, in fact they
can remove it altogether and just leave resolution of the local
hostname to the module, and it will magically follow whatever is
currently set via sethostname(). This module should be in the 'hosts'
line.

The way myhostname is currently implemented, it is rather problematic.
I think it has largely stopped stomping over the DNS namespace (with the
_gateway change), so it could be moved to the front, eliminating all
those problems.

The other issue is that the systemd NSS modules are quite heavy and pull
in other DSOs and may cause single-thread optimizations to be disabled
because they load libpthread.

Thanks,
Florian
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorapr

[Dominik 'Rathann' Mierzejewski]

On Thursday, 06 December 2018 at 15:10, Florian Weimer wrote:
[...]

Post by Florian Weimer
The way myhostname is currently implemented, it is rather problematic.
I think it has largely stopped stomping over the DNS namespace (with the
_gateway change), so it could be moved to the front, eliminating all
those problems.

That's news to me, what is this "_gateway" change? I noticed that in
a couple of traceroutes, but assumed it was an ISP thing. Are you telling
me this is a Fedora "feature"? Is this documented somewhere?

Regards,
Dominik
--
Fedora https://getfedora.org | RPMFusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorapro

[Zbigniew Jędrzejewski-Szmek]

Post by Dominik 'Rathann' Mierzejewski
[...]

Post by Florian Weimer
The way myhostname is currently implemented, it is rather problematic.
I think it has largely stopped stomping over the DNS namespace (with the
_gateway change), so it could be moved to the front, eliminating all
those problems.

That's news to me, what is this "_gateway" change? I noticed that in
a couple of traceroutes, but assumed it was an ISP thing. Are you telling
me this is a Fedora "feature"? Is this documented somewhere?

man nss-myhostname(8).

Zbyszek
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/d

[Tomasz Torcz]

Post by Dominik 'Rathann' Mierzejewski
[...]

Post by Florian Weimer
The way myhostname is currently implemented, it is rather problematic.
I think it has largely stopped stomping over the DNS namespace (with the
_gateway change), so it could be moved to the front, eliminating all
those problems.

That's news to me, what is this "_gateway" change? I noticed that in
a couple of traceroutes, but assumed it was an ISP thing. Are you telling
me this is a Fedora "feature"? Is this documented somewhere?

This is systemd feature. Looking into its NEWS file, gateway resolving
was added in v218, released 4 years ago, in December 2014.
It was changed to _gateway in v235, released in October 2017.

--
Tomasz Torcz 72->| 80->|
xmpp: ***@chrome.pl 72->| 80->|
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/***@lis

[Dominik 'Rathann' Mierzejewski]

Post by Tomasz Torcz

Post by Dominik 'Rathann' Mierzejewski
[...]

Post by Florian Weimer
The way myhostname is currently implemented, it is rather problematic.
I think it has largely stopped stomping over the DNS namespace (with the
_gateway change), so it could be moved to the front, eliminating all
those problems.

That's news to me, what is this "_gateway" change? I noticed that in
a couple of traceroutes, but assumed it was an ISP thing. Are you telling
me this is a Fedora "feature"? Is this documented somewhere?

This is systemd feature. Looking into its NEWS file, gateway resolving
was added in v218, released 4 years ago, in December 2014.
It was changed to _gateway in v235, released in October 2017.

Ok, I read man nss-myhostname and I do like the hostname and localhost
resolveability feature. I don't like the _gateway part though. Can I
have the former without the latter?

Regards,
Dominik
--
Fedora https://getfedora.org | RPMFusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorapro

[Zbigniew Jędrzejewski-Szmek]

Post by Dominik 'Rathann' Mierzejewski

Post by Tomasz Torcz

Post by Dominik 'Rathann' Mierzejewski
[...]

Post by Florian Weimer
The way myhostname is currently implemented, it is rather problematic.
I think it has largely stopped stomping over the DNS namespace (with the
_gateway change), so it could be moved to the front, eliminating all
those problems.

That's news to me, what is this "_gateway" change? I noticed that in
a couple of traceroutes, but assumed it was an ISP thing. Are you telling
me this is a Fedora "feature"? Is this documented somewhere?

This is systemd feature. Looking into its NEWS file, gateway resolving
was added in v218, released 4 years ago, in December 2014.
It was changed to _gateway in v235, released in October 2017.

Ok, I read man nss-myhostname and I do like the hostname and localhost
resolveability feature. I don't like the _gateway part though. Can I
have the former without the latter?

Not without patching systemd :]

Zbyszek
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/***@lists.fedoraproject.org

[Zbigniew Jędrzejewski-Szmek]

Post by Lennart Poettering

Post by Pavel Březina
Hello,

Heya!

Post by Pavel Březina
systemd and nss-mdns packages modifies nsswitch.conf in their %post
scriptlets which creates conflicts with authselect on systems that are
configured by authselect. This needs to be solved somehow.
Originally, I wanted to create an authselect command that can be used by
packages on systems that are configured by authselect and on systems that
are configured with different ways [1]. But it turned out that there are
only two packages that touches nsswitch.conf so I do not think this is
necessary.
I prepared initial design document with multiple solutions that came to my
mind [2] and I would like to discuss this with the community to see what is
the correct and desired way to solve this.

nss-systemd should be in nsswitch.conf by default. It's required for
systemd's DynamicUser=1 option to work correctly, and that's core
service functionality. Hence, given that systemd is Fedora's PID 1,
nss-systemd should also be in nsswitch.conf unconditionally (in the
'passwd' and 'group' lines). A system where nss-systemd is not enabled
is simply broken right now.
nss-myhostname should be in nsswitch.conf by default too. It's very
minimal, and just makes sure the local hostname remains resolvable all
the time. By enabling this, installers and image generators don't have
to patch /etc/hosts anymore like they traditionally did, in fact they
can remove it altogether and just leave resolution of the local
hostname to the module, and it will magically follow whatever is
currently set via sethostname(). This module should be in the 'hosts'
line.
Then there is nss-mymachines. It's primarily useful if
systemd-machined or systemd-nspawn is used. Given that those are now
part of the 'systemd-container' RPM it would be OK to also add
nss-mymachines to nsswitch.conf only when the RPM is installed, if
there's a concept for that. That said, in order to simplify things,
and given that systemd is a very core part of the OS I'd personally
just put it statically in nsswitch.conf too by default. After all a
missing NSS module listed in nsswitch.conf is just skipped, hence this
should not matter. This module should be in the 'passwd', 'group' and
'hosts' lines.
Finally, there's nss-resolve. It's the client side to
systemd-resolved. It's the client side to systemd-resolved's
DNS/mDNS/LLMNR/DoT/DNSSEC stack. systemd-resolved is not default in
Fedora right now. Quite frankly I think it should be, but that's another
political discussion (and I am not sure I am ready to have it right
now). The module is benign though: if resolved is not running it
doesn't do anything. It only does its thing if resolved is
running. Thus I'd also suggest to just enable it by default, and
simplify things because then people can use resolved just by doing
"systemctl enable systemd-resolved" and don't need to do anything
else. This module should be in the 'hosts' line.
Summary: I'd make things simple, and enable all four unconditionally
and by default without any dynamic infrastructure, without postinst
scripts or anything. If that's not acceptable, then at least two of the
four should be unconditionally enabled.

I also think we should "enable" them unconditionally, in the sense that
they should be configured in the default /etc/nsswitch.conf configurations.
As Lennart wrote, if the module is not installed in the filesystem, that
configuration has no effect. And if it is installed, but talks to an
inactive service, it has almost no effect too (apart from the linkage
and small runtime overhead). "Enabling" them in one consistent way in
the normal distro configuration seems much better to me then patching
it in, in a slightly different way on each installation.

In QA the subject of reducing the test matrix often comes up. This is
a nice opportunity: let's avoid having a nsswitch line that depends on
the installation order.
--
Also, we are not talking about whether those modules are active or not.
They *already* *are*, on any Fedora system where the configuration was
not overridden and the right packages are installed. The question is
*how* they should be enabled: either through the installed file or through
rpm scriptlets. Without those modules, too much stuff breaks, so disabling
them is not a realistic option.

Zbyszek
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/***@lists.

[Simo Sorce]

Post by Zbigniew Jędrzejewski-Szmek

Post by Lennart Poettering

Post by Pavel Březina
Hello,

Heya!

Post by Pavel Březina
systemd and nss-mdns packages modifies nsswitch.conf in their %post
scriptlets which creates conflicts with authselect on systems that are
configured by authselect. This needs to be solved somehow.
Originally, I wanted to create an authselect command that can be used by
packages on systems that are configured by authselect and on systems that
are configured with different ways [1]. But it turned out that there are
only two packages that touches nsswitch.conf so I do not think this is
necessary.
I prepared initial design document with multiple solutions that came to my
mind [2] and I would like to discuss this with the community to see what is
the correct and desired way to solve this.

nss-systemd should be in nsswitch.conf by default. It's required for
systemd's DynamicUser=1 option to work correctly, and that's core
service functionality. Hence, given that systemd is Fedora's PID 1,
nss-systemd should also be in nsswitch.conf unconditionally (in the
'passwd' and 'group' lines). A system where nss-systemd is not enabled
is simply broken right now.
nss-myhostname should be in nsswitch.conf by default too. It's very
minimal, and just makes sure the local hostname remains resolvable all
the time. By enabling this, installers and image generators don't have
to patch /etc/hosts anymore like they traditionally did, in fact they
can remove it altogether and just leave resolution of the local
hostname to the module, and it will magically follow whatever is
currently set via sethostname(). This module should be in the 'hosts'
line.
Then there is nss-mymachines. It's primarily useful if
systemd-machined or systemd-nspawn is used. Given that those are now
part of the 'systemd-container' RPM it would be OK to also add
nss-mymachines to nsswitch.conf only when the RPM is installed, if
there's a concept for that. That said, in order to simplify things,
and given that systemd is a very core part of the OS I'd personally
just put it statically in nsswitch.conf too by default. After all a
missing NSS module listed in nsswitch.conf is just skipped, hence this
should not matter. This module should be in the 'passwd', 'group' and
'hosts' lines.
Finally, there's nss-resolve. It's the client side to
systemd-resolved. It's the client side to systemd-resolved's
DNS/mDNS/LLMNR/DoT/DNSSEC stack. systemd-resolved is not default in
Fedora right now. Quite frankly I think it should be, but that's another
political discussion (and I am not sure I am ready to have it right
now). The module is benign though: if resolved is not running it
doesn't do anything. It only does its thing if resolved is
running. Thus I'd also suggest to just enable it by default, and
simplify things because then people can use resolved just by doing
"systemctl enable systemd-resolved" and don't need to do anything
else. This module should be in the 'hosts' line.
Summary: I'd make things simple, and enable all four unconditionally
and by default without any dynamic infrastructure, without postinst
scripts or anything. If that's not acceptable, then at least two of the
four should be unconditionally enabled.

I also think we should "enable" them unconditionally, in the sense that
they should be configured in the default /etc/nsswitch.conf configurations.
As Lennart wrote, if the module is not installed in the filesystem, that
configuration has no effect. And if it is installed, but talks to an
inactive service, it has almost no effect too (apart from the linkage
and small runtime overhead). "Enabling" them in one consistent way in
the normal distro configuration seems much better to me then patching
it in, in a slightly different way on each installation.
In QA the subject of reducing the test matrix often comes up. This is
a nice opportunity: let's avoid having a nsswitch line that depends on
the installation order.
--
Also, we are not talking about whether those modules are active or not.
They *already* *are*, on any Fedora system where the configuration was
not overridden and the right packages are installed. The question is
*how* they should be enabled: either through the installed file or through
rpm scriptlets. Without those modules, too much stuff breaks, so disabling
them is not a realistic option.

I wonder if we should think of a tighter system integration and subsume
the tasks of nss_machines into SSSD.
It would allow for detection and logging of UID conflicts should they
happen in a live system with the ability, for the admin to better
choose which of the pools should have priority in case of conflict ...

Simo.

--
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc

_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/dev

[Zbigniew Jędrzejewski-Szmek]

Post by Simo Sorce

Post by Zbigniew Jędrzejewski-Szmek

Post by Lennart Poettering

Post by Pavel Březina
Hello,

Heya!

Post by Pavel Březina
systemd and nss-mdns packages modifies nsswitch.conf in their %post
scriptlets which creates conflicts with authselect on systems that are
configured by authselect. This needs to be solved somehow.
Originally, I wanted to create an authselect command that can be used by
packages on systems that are configured by authselect and on systems that
are configured with different ways [1]. But it turned out that there are
only two packages that touches nsswitch.conf so I do not think this is
necessary.
I prepared initial design document with multiple solutions that came to my
mind [2] and I would like to discuss this with the community to see what is
the correct and desired way to solve this.

nss-systemd should be in nsswitch.conf by default. It's required for
systemd's DynamicUser=1 option to work correctly, and that's core
service functionality. Hence, given that systemd is Fedora's PID 1,
nss-systemd should also be in nsswitch.conf unconditionally (in the
'passwd' and 'group' lines). A system where nss-systemd is not enabled
is simply broken right now.
nss-myhostname should be in nsswitch.conf by default too. It's very
minimal, and just makes sure the local hostname remains resolvable all
the time. By enabling this, installers and image generators don't have
to patch /etc/hosts anymore like they traditionally did, in fact they
can remove it altogether and just leave resolution of the local
hostname to the module, and it will magically follow whatever is
currently set via sethostname(). This module should be in the 'hosts'
line.
Then there is nss-mymachines. It's primarily useful if
systemd-machined or systemd-nspawn is used. Given that those are now
part of the 'systemd-container' RPM it would be OK to also add
nss-mymachines to nsswitch.conf only when the RPM is installed, if
there's a concept for that. That said, in order to simplify things,
and given that systemd is a very core part of the OS I'd personally
just put it statically in nsswitch.conf too by default. After all a
missing NSS module listed in nsswitch.conf is just skipped, hence this
should not matter. This module should be in the 'passwd', 'group' and
'hosts' lines.
Finally, there's nss-resolve. It's the client side to
systemd-resolved. It's the client side to systemd-resolved's
DNS/mDNS/LLMNR/DoT/DNSSEC stack. systemd-resolved is not default in
Fedora right now. Quite frankly I think it should be, but that's another
political discussion (and I am not sure I am ready to have it right
now). The module is benign though: if resolved is not running it
doesn't do anything. It only does its thing if resolved is
running. Thus I'd also suggest to just enable it by default, and
simplify things because then people can use resolved just by doing
"systemctl enable systemd-resolved" and don't need to do anything
else. This module should be in the 'hosts' line.
Summary: I'd make things simple, and enable all four unconditionally
and by default without any dynamic infrastructure, without postinst
scripts or anything. If that's not acceptable, then at least two of the
four should be unconditionally enabled.

I also think we should "enable" them unconditionally, in the sense that
they should be configured in the default /etc/nsswitch.conf configurations.
As Lennart wrote, if the module is not installed in the filesystem, that
configuration has no effect. And if it is installed, but talks to an
inactive service, it has almost no effect too (apart from the linkage
and small runtime overhead). "Enabling" them in one consistent way in
the normal distro configuration seems much better to me then patching
it in, in a slightly different way on each installation.
In QA the subject of reducing the test matrix often comes up. This is
a nice opportunity: let's avoid having a nsswitch line that depends on
the installation order.
--
Also, we are not talking about whether those modules are active or not.
They *already* *are*, on any Fedora system where the configuration was
not overridden and the right packages are installed. The question is
*how* they should be enabled: either through the installed file or through
rpm scriptlets. Without those modules, too much stuff breaks, so disabling
them is not a realistic option.

I wonder if we should think of a tighter system integration and subsume
the tasks of nss_machines into SSSD.
It would allow for detection and logging of UID conflicts should they
happen in a live system with the ability, for the admin to better
choose which of the pools should have priority in case of conflict ...

Integration with sssd could be useful, dunno. But nss modules only report
existing usage of uids on the system. So by the time the nss modules are
invoked, it's already too late, in the sense that two completely unrelated
entities are sharing the user, possibly leading to unintended privilege
augmentation or information leakage. Nss modules are not useful to "choose"
anything.

Zbyszek
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel

[Lennart Poettering]

Post by Zbigniew Jędrzejewski-Szmek

Post by Simo Sorce
I wonder if we should think of a tighter system integration and subsume
the tasks of nss_machines into SSSD.
It would allow for detection and logging of UID conflicts should they
happen in a live system with the ability, for the admin to better
choose which of the pools should have priority in case of conflict ...

Integration with sssd could be useful, dunno. But nss modules only report
existing usage of uids on the system. So by the time the nss modules are
invoked, it's already too late, in the sense that two completely unrelated
entities are sharing the user, possibly leading to unintended privilege
augmentation or information leakage. Nss modules are not useful to "choose"
anything.

Yes, I agree fully. Announcing allocated users with NSS is one thing,
it's something we always should do, unconditionally. It's only
reasonably way to announce you took possession of a range. Actually
allocating ranges is a different discussion. It's a discussion worth
having, but is unrelated from the NSS discussion I think.

Lennart

[Lennart Poettering]

Post by Simo Sorce

Post by Zbigniew Jędrzejewski-Szmek

Post by Lennart Poettering
Summary: I'd make things simple, and enable all four unconditionally
and by default without any dynamic infrastructure, without postinst
scripts or anything. If that's not acceptable, then at least two of the
four should be unconditionally enabled.

I also think we should "enable" them unconditionally, in the sense that
they should be configured in the default /etc/nsswitch.conf configurations.
As Lennart wrote, if the module is not installed in the filesystem, that
configuration has no effect. And if it is installed, but talks to an
inactive service, it has almost no effect too (apart from the linkage
and small runtime overhead). "Enabling" them in one consistent way in
the normal distro configuration seems much better to me then patching
it in, in a slightly different way on each installation.
In QA the subject of reducing the test matrix often comes up. This is
a nice opportunity: let's avoid having a nsswitch line that depends on
the installation order.
--
Also, we are not talking about whether those modules are active or not.
They *already* *are*, on any Fedora system where the configuration was
not overridden and the right packages are installed. The question is
*how* they should be enabled: either through the installed file or through
rpm scriptlets. Without those modules, too much stuff breaks, so disabling
them is not a realistic option.

I wonder if we should think of a tighter system integration and subsume
the tasks of nss_machines into SSSD.
It would allow for detection and logging of UID conflicts should they
happen in a live system with the ability, for the admin to better
choose which of the pools should have priority in case of conflict ...

No disrespect, but think this would mean the layering is the wrong way
round: sssd is an add-on currently, a layer above systemd. systemd as
the lower layer really shouldn't call into higher layer stuff for
registering UIDs/GIDs. I mean, conceptually, higher level stuff should
call into lower level stuff but not the other way round. (And there's
also the problem that sssd is hardly universally accepted. systemd
probably runs on more systems not using sssd than on those using
sssd.)

Currently Linux has no nice protocol for registering UIDs or UID
ranges. In systemd we tried to make the best from what we got, and
what the layers underneath permit us (i.e. glibc NSS):

1. we always register the IDs we take possession of in NSS, to make
sure that it can be used as a comprehensive database of UID
registrations. (That's what the nss modules mentioned in my earlier
mail are about after all).

2. When picking a UID we check with NSS first if the UID is already
taken.

3. When picking a UID we also check if any IPC object is already owned
by the UID.

4. When checking whether UID is used we take the lckpwdf() lock first
(if we can, since its in /etc, i.e. potentially read-only), in
order to serialize registration. This sucks a bit admittedly, since
strictly speaking that lock is just about the file-based database
(i.e. /etc/passwd and friends). But it's the best there is, and it
is official glibc API.

We also documented in a lot of detail the UID/GID range assumptions we
make:

https://systemd.io/UIDS-GIDS

I think it would be great if we could come to a better protocol for
taking possession of UID ranges in the long run. But I still think the
best database for such allocation should be NSS itself, right
now. What would be great if we'd at least agree on a better lock file
though, maybe in /run. And maybe some rules that when you allocate
long UID ranges at once (like container managers do), that you only
have to NSS check key UIDs from it.

Lennart