On Thu, 2014-03-27 at 18:18 -0400, 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. Also let me add that NSCD wouldn't be a good solution anyway. NSCD is dumb (reason why we have our own similar mmap cache in nss_sss instead of using NSCD), and has no idea of the status of the network and will expire all caches after a while whether you regain access to the network or not, plus IIRC enumeration is never handled via NSCD so some operations will still fail hard. 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
