F21 System Wide Change: PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services

[Simo Sorce]

On Thu, 2014-03-27 at 22:59 +0100, Lennart Poettering wrote:
> On Wed, 26.03.14 13:43, Stephen Gallagher (sgallagh at redhat.com) 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