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@xxxxxxxxxxxxxxx>
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
