> >They are inet sockets as an IPC mechanism that has nothing to do with > >networking per se. Same with AF_UNIX sockets. That is, this privilege > >will both prevent use of the network and prevent applications that happen > >to use loopback and AF_UNIX sockets for IPC from working. We have no > >control over what applications those may be. > > Why would this affect AF_UNIX sockets?
Does your proposal allow socket() calls for AF_UNIX even without basic network privilege? If so, then no problem for AF_UNIX. > The basic privileges have added a new class of users, "subusers". > You can use it to contain applications (can't "call home") or users (can't > squirrel data away on the Internet). When removing a basic privilege, > the onus is on the administrator to determine that it will work for > the particular user. This itself is a supportability problem, but things become much worse if other (unrelated) functionality is ensnared by the privilege checks. > Follow on projects will allow us to select what INET connections can be > made; I do not believe that a carte blanche for "localhost" connections is > warranted: it allows sending email out through sendmail using the > submission port. I don't follow. How would mail actually be sent off the machine? Why should not having "network privileges" prevent applications from being used for local purposes? Further, the set of impacted applications will be essentially random based on the whim of the IPC mechanism used by its implementors. -- meem
