On Tue, 2009-12-22 at 17:27 +0100, Casper.Dik at Sun.COM wrote: > >On Tue, 2009-12-22 at 06:26 -0800, Casper Dik wrote: > >> This project proposes one new "basic" privilege. > >> > >> NET_ACCESS > >> Allows a process to open a network connection. > >> > >> The purpose of this privilege is the ability to create a process > >> confined to the current system. > > > >Semantic nit: This mechanism accomplishes that and more. For example, > >without this privilege, a process also cannot open a PF_INET* socket to > >communicate locally using the loopback address. I assume that this is > >an acceptable situation for the intended consumer, otherwise one would > >need some more complex mechanism (perhaps involving the proposed socket > >filter framework PSARC 2009/590). > > > True; however, we have sufficient local transport available
Sure, however that won't allow this mechanism to be used to restrict existing unmodified PF_INET* applications to loopback communication. I don't have a problem with that, it's simply a side-effect of the proposed solution. > and we also > have nscd; no need for ordinary applications to directly call the NIS/LDAP/ > DNS server. Right, and I think you may also have discovered libnsl's use of socket ioctls to get local address information while processing name lookup calls. It does that because nscd's address lists are unsorted, and getaddrinfo() and friends return a sorted address list using an algorithm that uses the local address list as input (this was introduced by PSARC 2002/390). That said, given that applications without the proposed privilege won't be able to communicate with the returned addresses, their sort order is quite meaningless. In that case, ignoring the failed socket() call and returning the unsorted address list directly from nscd would likely be the right thing to do. In any case, +1 from me. -Seb
