Peter Memishian writes: > > But more generally: if you revoke the ability to send and receive > > network packets from what appears to be a "non-networking" > > application, this will also revoke network access from libraries that > > this application calls. Figuring out what's affected by this seems to > > me to be a big part of figuring out how the feature could be used (and > > what it must do in order to be useful). > > I agree, though the same can be said for the existing privileges, which > has always concerned me. The only way I can see for this sort of stuff to > be robust in the face of patching is for certain "interesting" > implementation artifacts to be promoted to be part of the interfaces > themselves, but that may create more architectural problems than it > solves, especially in the long-run.
Or, perhaps, to allow libraries to (in some way) have privileges that are distinct from the applications with which they're bound. I know of no actual way to *do* that, but it seems to match the boundaries in this design and possibly others. The real issue I see with this proposal, though, is the conflation of UDP send and receive with TCP connect and accept. I don't think the ideas are really the same. So, I'd be somewhat in favor of having a big "network / don't network" switch, though with the issues around loopback and IPCs, I'm still a bit unclear on exactly what networking actually is. ;-} -- James Carlson, KISS Network <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
