What is the basic use case for this priv? Is it to let the admin "sandbox" somebody away from the network for security reasons, or is it a simple debugging tool to force-fail programs that use any form of networking? If the former, if it also disables key parts of the system that happen to use IPC in their implementation, it won't actually be useful; if the latter, have you characterized what parts of the system are disabled by it? Will a JVM even run? What about a graphical desktop? Is there anything that can be usefully done on the system if this priv is not available?
Maybe there needs to be both a "Local IPC Priv" for loopback usage and a "Network Priv" for all others... On Wed, Dec 23, 2009 at 2:34 PM, Alan Coopersmith <Alan.Coopersmith at sun.com> wrote: > How would this be any different than if they tried removing other basic > privileges, like the ability to fork() or exec(), from apps that really > needed it? If customers break their system, it's broken. I think the difference is that for those, the set of system middleware we provide doesn't silently rely on them for proper operation; loopback IPC isn't something (like exec()) that is an obvious side effect or implementation detail in a library... -John
