Date: Thu, 15 Feb 2007 15:22:59 +0000 From: Josef Karthauser <joe@FreeBSD.org> To: Jeremie Le Hen <jeremie@le-hen.org> Cc: hackers@freebsd.org, fs@freebsd.org Subject: Re: nullfs and named pipes. Message-ID: <20070215152259.GA2950@genius.tao.org.uk> In-Reply-To: <20070215135750.GR64768@obiwan.tataz.chchile.org> References: <20070204023711.GA3393@genius.tao.org.uk> <20070215135750.GR64768@obiwan.tataz.chchile.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--opJtzjQTFsWo+cga
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Feb 15, 2007 at 02:57:50PM +0100, Jeremie Le Hen wrote:
>=20
> 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.
>=20
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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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 =3D vp;
xp->null_lowervp =3D lowervp;
vp->v_type =3D lowervp->v_type;
+ if (vp->v_type =3D=3D VSOCK || vp->v_type =3D=3D VFIFO)
+ vp->v_un =3D lowervp->v_un;
vp->v_data =3D xp;
vp->v_vnlock =3D lowervp->v_vnlock;
if (vp->v_vnlock =3D=3D 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=20
srwxrwxrwx 1 mysql wheel 0 Jan 4 09:26 /tmp/mysql.sock
# mount_nullfs /tmp /mnt
# ls -ld /mnt/mysql.sock=20
srwxrwxrwx 1 mysql wheel 0 Jan 4 09:26 /mnt/mysql.sock
With a stock kernel this fails:
% mysql --socket=3D/mnt/mysql.sock=20
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=3D/mnt/mysql.sock=20
ERROR 1045 (28000): Access denied for user 'joe'@'localhost' (using pas=
sword: 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=3D/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
--opJtzjQTFsWo+cga
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (FreeBSD)
iEYEARECAAYFAkXUetMACgkQXVIcjOaxUBbbogCfZrNO34uk2z7eps+SUs2YrzOE
lokAoNOWAFev63KHT4KCIOXzQhDvxzCQ
=joYw
-----END PGP SIGNATURE-----
--opJtzjQTFsWo+cga--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070215152259.GA2950>