nullfs and named pipes.

[Julian Elischer]

Josef Karthauser wrote:
> On Thu, Feb 15, 2007 at 02:57:50PM +0100, Jeremie Le Hen wrote:
>> Note that all processes within a jail can only intefere with processes
>> from another jail or host as if they were on different machines.  This
>> means they can communicate through PF_INET for instance but not
>> PF_LOCAL.
>>
> 
> You might think so!  However that's not what's going on here.
> 


Yes I tried to do this once before and failed.. I was trying to 
have the same named pipes available in two chroots (not jails) and 
it failed as you say. I would certainly like to have this fixed.

Does anyone know if our nullfs rewrite is related at all to the\
dragonfly nullfs rewrite? They say lots of good things about the
dragonfly rewrite....


> The named pipe/nullfs issue is nothing to do with jails.  It's just
> that nullfs is broken with respect to named pipes as I've previously
> reported.  However with this patch:
> 
>     cvs diff: Diffing .
>     Index: null_subr.c
>     ===================================================================
>     RCS file: /home/ncvs/src/sys/fs/nullfs/null_subr.c,v
>     retrieving revision 1.48.2.1
>     diff -u -r1.48.2.1 null_subr.c
>     --- null_subr.c 13 Mar 2006 03:05:17 -0000      1.48.2.1
>     +++ null_subr.c 14 Feb 2007 00:02:28 -0000
>     @@ -235,6 +235,8 @@
> 	    xp->null_vnode = vp;
> 	    xp->null_lowervp = lowervp;
> 	    vp->v_type = lowervp->v_type;
>     +       if (vp->v_type == VSOCK || vp->v_type == VFIFO)
>     +               vp->v_un = lowervp->v_un;
> 	    vp->v_data = xp;
> 	    vp->v_vnlock = lowervp->v_vnlock;
> 	    if (vp->v_vnlock == NULL)
> 
> that problem goes away.  Now a named pipe created on a lower layer
> can be spoken to by a process connecting to it on a higher layer,
> i.e (for demostration purposes only):
> 
>     # ls -ld /tmp/mysql.sock 
>     srwxrwxrwx  1 mysql  wheel  0 Jan  4 09:26 /tmp/mysql.sock
>     # mount_nullfs /tmp /mnt
>     # ls -ld /mnt/mysql.sock 
>     srwxrwxrwx  1 mysql  wheel  0 Jan  4 09:26 /mnt/mysql.sock
> 
> With a stock kernel this fails:
> 
>     % mysql --socket=/mnt/mysql.sock 
>     ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/mnt/mysql.sock' (61)
> 
> but with the patch above it works:
> 
>     % mysql --socket=/mnt/mysql.sock 
>     ERROR 1045 (28000): Access denied for user 'joe'@'localhost' (using password: NO)
> 
> Of course the patch above doesn't work if the socket is created at
> /mnt/mysql.sock and something wants to talk to it over at
> /tmp/mysql.sock, however that is not really a problem.
> 
> 
> So how does this relate to jails?
> 
> The point of using nullfs is to make a PF_LOCAL socket appear local
> even in the jail(!).  Using the patch above this is indeed the case
> and as far as the jail is concerned the socket is indeed local,
> meaning that a process within a jail can talk via it to a process
> on the host environment with no restrictions.  This is crucially
> important for mysql for instance as there is significant overhead
> associated with PF_INET connections which can be avoided by talking
> to PF_LOCAL sockets.

this is something I need to be able to do.

> 
>> IOW you have to think your jails as if theey were multiples boxes.
>> You should therefore make them communicate with networking sockets and
>> protect the latter with firewalling rules or tcpwrapper.
> 
> Now in terms of protecting the host environment this is trivially done
> by using a read-only nullfs mount:
> 
>     # mkdir /mysql
>     # mysqld_safe --socket=/mysql/mysql.sock &
> 
>     # mount_nullfs -oro /mysql /jail/mysql
> 
> voila.  The database can now be connected to within the jail environment
> on /mysql/mysql.sock as a local fast connection, but as /mysql is
> mounted read-only they cannot do anything other than connect to the
> socket :).
> 

yep

> 
> Remember tools not policy :).
> 
> Joe