-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/27/2014 06:18 PM, Simo Sorce wrote: > On Thu, 2014-03-27 at 22:59 +0100, Lennart Poettering wrote: >> On Wed, 26.03.14 13:43, Stephen Gallagher (sgallagh@xxxxxxxxxx) >> wrote: >> >>>> Note that PrivateNetwork=yes should not be used for: >>>> >>>> 1. Services that actually require network access (with the >>>> exception of daemons only needing socket activation) 2. >>>> Services which may be used to execute arbitrary user or >>>> administrator supplied programs. (see above) 3. Services >>>> which might need to resolve non-system user and group names. >>>> Since on some setups resolving non-system users might require >>>> network access to an LDAP or NIS server, enabling this option >>>> on might break resolving of these user names. Note however >>>> that system users/groups are always resolvable even without >>>> network access. Hence it is safe to enable this option for >>>> daemons which just need to resolve their own system user or >>>> group name. >>> >>> This may not be a safe statement to make. I personally know of >>> a great many deployments where admins have removed the local >>> accounts for >> >> Well, this assumption is built into a lot of software we do, for >> example all across device management, tmpfiles and suchlike. >> System users must be resolvable without network, we cannot delay >> bootup for these components, just because the network isn't up >> yet... >> >> It's OK to if normal users are only resolvable with the network >> round. And it's OK to sync system user IDs across the network, >> but they must be resolvable at any time -- they are integral part >> of the core OS after all. >> >> People can use a caching daemon (like sssd?) if they like, to >> make sure the system users stay in syn across the network, but >> removing them from /etc/passwed entirely is nothing we ever >> supported or should support. >> >> I mean, it's even OK if people "hack" things that way, if they >> want to shoot themselves in the foot, and know what they do. But >> that really shouldn't stop us from deploying PrivateNetwork=yes, >> since there is a very easy way out for them: just enable nscd. >> With nscd enabled the NSS calls will go via the nscd AF_UNIX >> socket in the fs (which is connectable, regardless of >> PrivateNetwork=yes), and then the actual query is made from nscd. >> Or actually, to top that, people who have setups like that, and >> store their user databases on the network, for example in LDAP, >> are the ones nscd has been written for in the first place, and >> hence there's really very little changing for them. >> >> But anyway, it's a hack to allow system users to be removed from >> /etc/passwd. It's already broken if you want to support that, you >> have to file bugs to udev, tmpfiles and so on. And yuck, I don't >> even see how that could ever work... >> >>> We'd need to think very hard about whether any service should >>> have this turned on by default. If we *do* enable it by >>> default, we should also carefully document how to turn it off >>> for those services if they rely on centrally-managed accounts. >> >> I think we can cover this one line: "if you do something like >> that, don't. if you insist, use nscd". And that should be >> enough. > > It is doable without issues and withut needing nscd with sssd, so I > do not think we need to CYA with this line at all. Yes, see elsewhere in this thread. I was forgetting that the remote capability doesn't happen in-process, it happens as part of the SSSD daemon (which obviously wouldn't use PrivateNetwork=yes). It's more of a risk with the old nss_ldap, but I don't think we even ship that anymore (replaced with nss-pam-ldapd) As long as this isn't in any way interfering with UNIX sockets (which it must not be, if nscd would work), then I see no issue here with SSSD. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlM1YTkACgkQeiVVYja6o6NlMQCgqPy86NQ175UsOzQ6Og3ODbbe YOMAoIBO0ZhbueWMlTdwFKYT2IhhNt/s =GyTT -----END PGP SIGNATURE----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
