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

[Lennart Poettering]

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.

Lennart

-- 
Lennart Poettering, Red Hat