-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/27/2014 06:18 PM, Simo Sorce wrote:
On Thu, 2014-03-27 at 22:59 +0100, Lennart Poettering wrote:
> On Wed, 26.03.14 13:43, Stephen Gallagher (sgallagh(a)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.
Yes, see elsewhere in this thread. I was forgetting that the remote
capability doesn't happen in-process, it happens as part of the SSSD
daemon (which obviously wouldn't use PrivateNetwork=yes). It's more of
a risk with the old nss_ldap, but I don't think we even ship that
anymore (replaced with nss-pam-ldapd)
As long as this isn't in any way interfering with UNIX sockets (which
it must not be, if nscd would work), then I see no issue here with SSSD.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlM1YTkACgkQeiVVYja6o6NlMQCgqPy86NQ175UsOzQ6Og3ODbbe
YOMAoIBO0ZhbueWMlTdwFKYT2IhhNt/s
=GyTT
-----END PGP SIGNATURE-----