On Tue, Apr 15, 2008 at 03:16:09PM -0700, Garrett D'Amore wrote: > Comparing noaccess and daemon, I agree that there is little difference > between the two. (ISTR however that NFS had some special handling > around noaccess, or maybe that is nobody. I never did anything that > relied on the special semantics, in any case.)
You're thinking of nobody. (heh) > HOWEVER, one could reasonably argue *separate* UID/GIDs could be used to > provide better security isolation. I.e., it makes sense that if someone I agree. > finds a hack for nbtd, that we might not want that to create an exposure > for kcfd, or nfsd, etc. (E.g. imagine that you can now attach a > debugger to nfsd because you hacked nbt...) > > It would be really nice if we had a better way to allocate special > purpose UIDs for these sorts of things, without worrying about > [...] We almost do! Now that we have an ephemeral ID concept we could have idmapd provide an ephemeral ID allocation service for this purpose. Another possibility is that the kernel allocates a range of ephemeral IDs for this purpose before idmapd starts. Since there will be few of these we might as well have the kernel provide the allocation and name service. The only thing is: we still need a user/group namespace for such IDs that won't conflict with customers. But then, that's never stopped us from allocating new ones in /etc/passwd and /etc/group, so it's not necessarily a serious concern. Still: not this case. Or does the ARC think now's the time to put its foot down on this issue? Keep in mind that adding such a service to idmapd is not something we can turn around in a week, say. A kernel- based service could possibly be added more quickly, and IMO would be a better architecture. Nico --
