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

[Simo Sorce]

On Thu, 2014-03-27 at 08:06 -0400, Stephen Gallagher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 03/27/2014 12:30 AM, William Brown wrote:
> > On Wed, 2014-03-26 at 13:43 -0400, Stephen Gallagher wrote:
> >> On 03/26/2014 10:06 AM, Jaroslav Reznik wrote:
> >> 
> >> <snip>
> >>> 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 their services and instead rely on LDAP accounts.
> >> (This is mostly to guarantee that the file ownership of these
> >> services is the same user on all systems, which they may not be
> >> if the local account was created using the 'get-next-free-id'
> >> approach).
> >> 
> >> 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.
> > 
> > Would PrivateNetwork break interactions with SSSD? If you used that
> > to provide nsswitch, then it may not be such an issue.
> > 
> 
> Hmm, good point. It would be talking to SSSD via a local socket.
> Naturally this feature wouldn't affect the SSSD daemon. So yeah, that
> would probably work just fine. I didn't think that all the way through
> originally.
> 
> This probably can break people using nss_ldap or nss_winbind, though.

Only people using the old nss_ldap.
nss_ldapd, nss_winbind, like nss_sss talks to a daemon on a local
socket.

I honestly think people should stop using the old nss_ldap, and I think
most already migrated to one of the superior choices in Fedora land, so
I see no particular issue from this point of view.

however there are deployments that still need to access ldap directly in
some case (I am thinking autofs maps store on ldap for example).

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York