15 messages in org.freebsd.freebsd-hackersnullfs and named pipes.| From | Sent On | Attachments |
|---|---|---|
| Josef Karthauser | Feb 4, 2007 2:57 am | |
| Eric Anderson | Feb 6, 2007 4:48 pm | |
| Josef Karthauser | Feb 7, 2007 10:47 am | |
| Jeremie Le Hen | Feb 15, 2007 2:21 pm | |
| Josef Karthauser | Feb 15, 2007 3:22 pm | |
| Kostik Belousov | Feb 15, 2007 3:31 pm | |
| Josef Karthauser | Feb 15, 2007 4:34 pm | |
| Julian Elischer | Feb 15, 2007 6:11 pm | |
| Jeremie Le Hen | Feb 16, 2007 10:30 am | |
| Robert Watson | Feb 16, 2007 12:54 pm | |
| Kostik Belousov | Feb 16, 2007 2:36 pm | |
| Josef Karthauser | Feb 18, 2007 10:41 pm | |
| Robert Watson | Feb 19, 2007 2:01 pm | |
| Robert Watson | Feb 19, 2007 2:08 pm | |
| Robert Watson | Feb 19, 2007 2:28 pm |
| Subject: | nullfs and named pipes. | |
|---|---|---|
| From: | Josef Karthauser (jo...@FreeBSD.org) | |
| Date: | Feb 15, 2007 3:22:50 pm | |
| List: | org.freebsd.freebsd-hackers | |
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.
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.
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 :).
Remember tools not policy :).
Joe