Garrett D'Amore wrote: > 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.)
It is the nobody account that is special to NFS: nobody:x:60001:60001:NFS Anonymous Access User:/: noaccess:x:60002:60002:No Access User:/: nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/: > 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...) That is fine but we only have a limited number (gid and uid 0 through 100) the upside is we have only allocated 19 of those so far. > It would be really nice if we had a better way to allocate special > purpose UIDs for these sorts of things, without worrying about Exactly what is wrong with the process we use just now ? The range 0 through 100 is reserved and PSARC deals with the allocation with the repository being the source of the /etc/passwd and /etc/group files in the current ON gate. Because we only have a limited number we have been taking the stance that unless the service needs to own files that it needs to modify then it should not need a uid of its own. In addition to running as daemon it is also recommended to remove the basic privileges proc_info and proc_session which gives a lot of the benefits of running as a different uid for each process. This has all been covered in previous cases that dealt with uid allocation. Maybe I should write it up in a best practice. -- Darren J Moffat
