UNIX domain sockets on nullfs still broken?

Ivan Voras ivoras at freebsd.org
Thu Dec 10 09:59:42 UTC 2009

2009/12/10 Robert Watson <rwatson at freebsd.org>:
> On Tue, 1 Dec 2009, Linda Messerschmidt wrote:
>> On Mon, Nov 30, 2009 at 10:14 AM, Ivan Voras <ivoras at 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...

More information about the freebsd-hackers mailing list