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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
