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

[William Brown]

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. 



-- 
William Brown <william at firstyear.id.au>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 876 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140327/c89e1d60/attachment.sig>