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