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. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
