2009/12/10 Robert Watson <rwat...@freebsd.org>: > > On Tue, 1 Dec 2009, Linda Messerschmidt wrote: > >> On Mon, Nov 30, 2009 at 10:14 AM, Ivan Voras <ivo...@freebsd.org> wrote: >>>> >>>> What's the sane solution, then, when the only method of communication >>>> is unix domain sockets? >>> >>> It is a security problem. I think the long-term solution would be to add >>> a >>> sysctl analogous to security.jail.param.securelevel to handle this. >> >> Out of curiosity, why is allowing accessing to a Unix domain socket in a >> filesystem to which a jail has explicitly been allowed access more or less >> secure than allowing access to a file or a devfs node in a filesystem to >> which a jail has explicitly been allowed access? > > (I seem to have caught this thread rather late in the game due to being on > travel) -- Ivan is wrong about nullfs, it's broken due to a bug, not a > feature, and that bug is not present when using a single file system. He's > thinking of unionfs semantics, where if it worked it would be a bug. :-)
You have a point there. I was actually thinking more of sysvshm - which doesn't have anything to do with any of the issues here - but has some of the same properties (and is also used by databases - e.g. postgresql, which I'm using daily so it sort of cross-linked). The reason I'd like the nullfs barrier kept is that it (like shm) is used for IPC, and in this case, IPC across different jails (though a file system itself also be used so...). It's not a big issue - I'll also accept that it's the operator's fault if he doesn't know sharing file systems will also share sockets and fifos on it... _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
