Darren J Moffat wrote:
> Gary Winiger wrote:
>>> Why can't it run as uid and gid daemon ?
>>
>> Or better yet, noaccess?
>
> No not better at all IMO, as user accounts one is no better than the
> other. However is more current use of daemon than noaccess (kcfd,
> rpcbind, nfsd, statd, lockd, for starters) in Solaris services. Also
> daemons running as daemon looks reasonable, "noaccess" looks strange
> (to me anyway).
>
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.)
HOWEVER, one could reasonably argue *separate* UID/GIDs could be used to
provide better security isolation. I.e., it makes sense that if someone
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
collisions with site use of UIDs or collisions with other OS' use of
UIDs (for shared NIS maps, for example.) Almost like a completely
different number space for system use only, that was guaranteed not to
collide with any other UIDs. Gary, do you have any thoughts here? (I
realize that such a project is far outside of the scope of this project,
although the notion of possibly selected a different low numbered UID
for nbt seems not entirely out of scope.)
-- Garrett
