Re: Configuration differences for jails
From: Jeremie Le Hen [EMAIL PROTECTED] To: Jas arlerr [EMAIL PROTECTED] CC: [EMAIL PROTECTED], freebsd-hackers@freebsd.org Subject: Re: Configuration differences for jails Date: Fri, 22 Apr 2005 17:41:40 +0200 Hi, I am not very familar with mount_nullfs, but i think it is _one_ copy with _multiple_ references(FIXME).So if we modify something in one jail, the same effect will also impose on other jails,even the real machine. Due to this problem, readonly mounts may be a good choice. Usually, /bin and others are never modified, that's why it may be null mounted readonly. If you want to be able to write to these directories from inside the jail, there are two methods : - First is to use mount_unionfs(8) which will mount another directory above the null mounted directory. Note that unionfs is currently known to be broken, although there are no official list of known bugs, AFAIK. Having a null mount AND an union mount over it may perhaps introduce a non-negligible overhead, I guess. - Make each jail have its own world. BUT if we do some things related to the /etc files, such as passwd, ro mounts can not deal with this situation because different jails need different passwd files for private users. So I think this can only be done by making a copy of relevant files but not ro mounts. Once again, /etc is not intended to be null mounted. It contains sensitive informations about the host that should not be published in jails. You will have to use the distribution make target from /usr/src/etc (see my previous email). I see! Thanks for your explanation! regards Jas _ MSN Messenger: http://messenger.msn.com/cn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Configuration differences for jails
I've seen them mentioned again in this thread. There apparently is a make distribution target designed to address /etc, but I can't find it anywhere. cd /usr/src/etc # This will create the standard directory hierarchy using mtree(8). make DESTDIR=/jail distrib-dirs # This will install a default /etc, IIUC. make DESTDIR=/jail distribution -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Configuration differences for jails
From: Joerg Sonnenberger [EMAIL PROTECTED] To: freebsd-hackers@freebsd.org Subject: Re: Configuration differences for jails Date: Thu, 21 Apr 2005 13:43:59 +0200 On Thu, Apr 21, 2005 at 07:39:08AM -0400, c0ldbyte wrote: Now if that last question is correct and thats the proccess you are using to create a jail then depending on the situation wouldnt that inturn defeat some of the main purposes of the jail, like the following. If you mounted your /bin on /mnt/jail/bin then if a person that was looking to break in and effect the system that is currently locked in the jail all he would have to do is just write something to the jail/bin which is actualy your root /bin and then the next time a binary is used from your root directories it could still infect the rest of the system ultimately defeating the purpose of what you just set up. To my understanding and use a jail is somewhat totaly independent of the OS that it resides in and wont be if you are using nullfs to mount root binary directories on it. ro mount as written by grant parent protects against this. I am not very familar with mount_nullfs, but i think it is _one_ copy with _multiple_ references(FIXME).So if we modify something in one jail, the same effect will also impose on other jails,even the real machine. Due to this problem, readonly mounts may be a good choice. BUT if we do some things related to the /etc files, such as passwd, ro mounts can not deal with this situation because different jails need different passwd files for private users. So I think this can only be done by making a copy of relevant files but not ro mounts. Any idea? regards Jas _ MSN Hotmail http://www.hotmail.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Configuration differences for jails
# This will create the standard directory hierarchy using mtree(8). make DESTDIR=/jail distrib-dirs For the record, I discovered the hierarchy make target in /usr/src/Makefile.inc. I think we ought to use this one instead on the internal distrib-dirs target. -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Configuration differences for jails
Hi, I am not very familar with mount_nullfs, but i think it is _one_ copy with _multiple_ references(FIXME).So if we modify something in one jail, the same effect will also impose on other jails,even the real machine. Due to this problem, readonly mounts may be a good choice. Usually, /bin and others are never modified, that's why it may be null mounted readonly. If you want to be able to write to these directories from inside the jail, there are two methods : - First is to use mount_unionfs(8) which will mount another directory above the null mounted directory. Note that unionfs is currently known to be broken, although there are no official list of known bugs, AFAIK. Having a null mount AND an union mount over it may perhaps introduce a non-negligible overhead, I guess. - Make each jail have its own world. BUT if we do some things related to the /etc files, such as passwd, ro mounts can not deal with this situation because different jails need different passwd files for private users. So I think this can only be done by making a copy of relevant files but not ro mounts. Once again, /etc is not intended to be null mounted. It contains sensitive informations about the host that should not be published in jails. You will have to use the distribution make target from /usr/src/etc (see my previous email). Regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Configuration differences for jails
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 20 Apr 2005, Jeremie Le Hen wrote:
I'm trying to untangle myself on this issue. I have different
filesystems for /, /usr, and /usr/local, mounted in unusual places:
504,p0,1$ ls -l /usr{,/X11R6,/local}
lrwxr-xr-x 1 root wheel 18 7 nov 2003 /usr - fs/base/mount/usr/
lrwxr-xr-x 1 root wheel 25 8 nov 2003 /usr/X11R6 -
../../../apps/mount/X11R6
lrwxr-xr-x 1 root wheel 25 18 abr 20:40 /usr/local -
../../../apps/mount/local
I know I want to share /usr, but not /usr/local, and only parts of /. So
I mount_unionfs /fs/base inside the jail:
above:/fs/base/mount on /fs/jaildata/mount/fs/base/mount (unionfs,
local, read-only, noclusterw)
mount_nullfs(8) will mount one directory and all its content onto another
one, but there is no way to exclude one of the subdirectory. You
will instead have to mount each subdirectory you need, not more. One
other way do achieve this is to make a second null mount over the
directory you don't wan't to share (/usr/local) but I'm not aware of
the consequences of such setup in term of performance and stability.
But this way I don't get the automagically upgrade virtual hosts
behaviour I want, since I'm missing /{,s}bin, /lib and /libexec and I
definitely don't want to share /etc.
You won't have a one to one mapping between jail and null mounts. There
are generally multiple null mounts for a unique jail.
Considering your jail root is /jail/test, and you enabled the
jail_$jail_mount (jail_test_mount here) rc.conf(5) variable, here is
the content of /etc/fstab.test :
%%%
/bin/jail/test/bin nullfs ro 0 0
/sbin /jail/test/sbin nullfs ro 0 0
/lib/jail/test/lib nullfs ro 0 0
/libexec/jail/test/libexec nullfs ro 0 0
/usr/bin/jail/test/usr/bin nullfs ro 0 0
/usr/sbin /jail/test/usr/sbin nullfs ro 0 0
/usr/lib/jail/test/usr/lib nullfs ro 0 0
/usr/libexec/jail/test/usr/libexec nullfs ro 0 0
/usr/libdata/jail/test/usr/libdata nullfs ro 0 0
/usr/share /jail/test/usr/sharenullfs ro 0 0
/usr/compat /jail/test/usr/compat nullfs ro 0 0
%%%
I don't think it's easy to take /etc/ outside the root fs, but I don't
see how to share /bin or /lib without leaking info.
How do you handle this? What are those distribution targets and how can
I use them?
As I said above, null mount each directory.
Regards,
Now I havent caught this whole thread but to my understanding right now
you are talking about mounting nullfs's from the root filesystem /
onto the jail correct ?.
Now if that last question is correct and thats the proccess you are using
to create a jail then depending on the situation wouldnt that inturn
defeat some of the main purposes of the jail, like the following. If you
mounted your /bin on /mnt/jail/bin then if a person that was looking
to break in and effect the system that is currently locked in the jail
all he would have to do is just write something to the jail/bin which is
actualy your root /bin and then the next time a binary is used from your
root directories it could still infect the rest of the system ultimately
defeating the purpose of what you just set up. To my understanding and use
a jail is somewhat totaly independent of the OS that it resides in and
wont be if you are using nullfs to mount root binary directories on it.
With all due respect This is a bad idea given allmost any situation
that you would have to create a jail for a unsafe proccess or users.
- --
( When in doubt, use brute force. -- Ken Thompson 1998 )
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (FreeBSD)
Comment: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xF7DF979F
Comment: Fingerprint = D1DC 0AA4 1C4E EAD4 24EB 7E77 B261 50BA F7DF 979F
iD8DBQFCZ5DfsmFQuvffl58RAi6FAJ4n1JeS/MCN2s7zowgWrMAzdnarowCfUQ5n
sVhxoQT+nepoMnj/yYckQbs=
=+Vmn
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Configuration differences for jails
On Thu, Apr 21, 2005 at 07:39:08AM -0400, c0ldbyte wrote: Now if that last question is correct and thats the proccess you are using to create a jail then depending on the situation wouldnt that inturn defeat some of the main purposes of the jail, like the following. If you mounted your /bin on /mnt/jail/bin then if a person that was looking to break in and effect the system that is currently locked in the jail all he would have to do is just write something to the jail/bin which is actualy your root /bin and then the next time a binary is used from your root directories it could still infect the rest of the system ultimately defeating the purpose of what you just set up. To my understanding and use a jail is somewhat totaly independent of the OS that it resides in and wont be if you are using nullfs to mount root binary directories on it. ro mount as written by grant parent protects against this. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Configuration differences for jails
From: Jeremie Le Hen [EMAIL PROTECTED] To: ?? ?? [EMAIL PROTECTED] CC: freebsd-hackers@freebsd.org Subject: Re: Configuration differences for jails Date: Wed, 20 Apr 2005 16:37:15 +0200 Now with some distance, I must admit that all this gymnastic is quite boring. I now decided to run two virtual hosts as they are managed in a very natural way. These two hosts are just like two real boxes, one running Bind and the other one running Postfix. When I need to update something in the configuration, I login to the box with ssh(1). This take some more memory and in principle no CPU as all processes are sleeping most of the time. I forgotten to explain that using virtual hosts require some administration too in order to avoid wasting disk space. The jail(8) manual page advices to make world with DESTDIR set. I prefer using null mounts as it doesn't require additional disk space and an upgrade of the host will automagically upgrade virtual hosts. You will nevertheless have to make distribution and distrib-dirs. Here are the directories I advice you to share : /bin /sbin /lib /libexec /usr/bin /usr/sbin /usr/lib /usr/libexec /usr/libdata /usr/share /usr/doc /usr/compat /usr/ports Sharing ports may be more difficult as it may require sharing the port database, but I think it's still possible. Good idea! I will take a try! Regards Jas _ MSN Hotmail http://www.hotmail.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Configuration differences for jails
On Thu, 21 Apr 2005, Joerg Sonnenberger wrote: On Thu, Apr 21, 2005 at 07:39:08AM -0400, c0ldbyte wrote: Now if that last question is correct and thats the proccess you are using to create a jail then depending on the situation wouldnt that inturn defeat some of the main purposes of the jail, like the following. If you mounted your /bin on /mnt/jail/bin then if a person that was looking to break in and effect the system that is currently locked in the jail all he would have to do is just write something to the jail/bin which is actualy your root /bin and then the next time a binary is used from your root directories it could still infect the rest of the system ultimately defeating the purpose of what you just set up. To my understanding and use a jail is somewhat totaly independent of the OS that it resides in and wont be if you are using nullfs to mount root binary directories on it. ro mount as written by grant parent protects against this. Joerg Right, I saw the (ro) option as you specified, but still there have been flaws in the sytem and forseen more flaws to come as allmost any programmer these days come accross and to just rely on it being (ro) just seems kind of not something that you should look to totaly to protect the system that the jail resides on. Even though in the unpredicted future a jail could be broken out of to such a instance I consider it to be a safer practice to just make installworld $DESTDIR make distribution DESTDIR=$DESTJAIL -DNO_MAKEDEV_RUN and just delete stuff out of $DESTJAIL that you dont need for things to run properly and then there is never a instance or less of a chance that things will go wrong for you. As I said before depending on the use of the jail as well would also be a determination on how the jail is setup to but should never interact with the main system that holds the jail. Thats only my opinion though and just releaves thought about other security issues that deal with the main part of the system. -- ( When in doubt, use brute force. -- Ken Thompson 1998 ) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Configuration differences for jails
On Thu, Apr 21, 2005 at 08:23:46AM -0400, c0ldbyte wrote: On Thu, 21 Apr 2005, Joerg Sonnenberger wrote: On Thu, Apr 21, 2005 at 07:39:08AM -0400, c0ldbyte wrote: Now if that last question is correct and thats the proccess you are using to create a jail then depending on the situation wouldnt that inturn defeat some of the main purposes of the jail, like the following. If you mounted your /bin on /mnt/jail/bin then if a person that was looking to break in and effect the system that is currently locked in the jail all he would have to do is just write something to the jail/bin which is actualy your root /bin and then the next time a binary is used from your root directories it could still infect the rest of the system ultimately defeating the purpose of what you just set up. To my understanding and use a jail is somewhat totaly independent of the OS that it resides in and wont be if you are using nullfs to mount root binary directories on it. ro mount as written by grant parent protects against this. Joerg Right, I saw the (ro) option as you specified, but still there have been flaws in the sytem and forseen more flaws to come as allmost any programmer these days come accross and to just rely on it being (ro) just seems kind of not something that you should look to totaly to protect the system that the jail resides on. Even though in the unpredicted future a jail could be broken out of to such a instance I consider it to be a safer practice to just make installworld $DESTDIR make distribution DESTDIR=$DESTJAIL -DNO_MAKEDEV_RUN and just delete stuff out of $DESTJAIL that you dont need for things to run properly and then there is never a instance or less of a chance that things will go wrong for you. As I said before depending on the use of the jail as well would also be a determination on how the jail is setup to but should never interact with the main system that holds the jail. Thats only my opinion though and just releaves thought about other security issues that deal with the main part of the system. Well he's per his statement using it in a virtual server environment where he would simply like to ease administrative work by reducing the number of jails that need to be upgraded every time. The likelyhood of there being an issue with read only mounts is quite low. I'd consider the ability to break out of a jail as more of a threat than that. Additionally, I'm pretty sure it wouldn't be very difficult to prove that there are no issues with this. Read only mounts are so useful, and frequent, that I'm quite sure we'd know if there were security issues with them. As with any jail, you are in part trusting the security of the main machine, since it has access to all the jailed environments. I'd be worried about this being compromised before I point out possible (non-existant) issues with read-only mounts. --Devon -- ( When in doubt, use brute force. -- Ken Thompson 1998 ) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] !DSPAM:42679acd458596534657138! pgp7y860eARhU.pgp Description: PGP signature
Re: Configuration differences for jails
* Jeremie Le Hen [EMAIL PROTECTED] [20050420 18:55]: [snip much appreciated example] I don't think it's easy to take /etc/ outside the root fs, but I don't see how to share /bin or /lib without leaking info. How do you handle this? As I said above, null mount each directory. Thanks, that was exactly what I was looking for. I hadn't read close enough to appreciate the difference betwen unionfs and nullfs until now. What are those distribution targets and how can I use them? I've seen them mentioned again in this thread. There apparently is a make distribution target designed to address /etc, but I can't find it anywhere. qvb -- pica ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Configuration differences for jails
Hi, I am now trying to use jail in FreeBSD. I have read the jail(8) man page and some others documents for setting up jails. But I'm a little confused about the procedure and configurations for setting up jails. As known to all, jail can be used for two purposes, i.e. jailing a single application or acting as a virtual host. What i want to know is the concrete configuration (procedure) difference between the two types use of jails. Is there a SMALLEST set of configuration necessary for setting up a jail? If so, what is it? Another question, is there any way to detect the share of files between multiple jails automatically? The following is based on my own experience and therefore may not be what other people feel. I run two main services on a box, Bind and Postfix, and I wanted to separate each other from the base system for security reason. I thought it was quite heavy to boot two virtual hosts as described in the jail(8) manpage for two daemons only, so I decided to just jail each application. In all cases, I strongly wanted the chosen setup to create a very few overhead compared to what it would be without jail. In the per-application case, you will have to be very careful about the things that will be needed by the daemon (dynamic libraries and configuration files as well as spool queues, mailboxes or maildirs, and other filesystem objects such as Unix domain sockets, named pipes, ...) Since I wanted this setup to be as transparent as possible, I decided to null mounts all needed directories from host to jail root, in order to be able to execute administrative commands (postconf(8), mailq(8), ...) from host itself. One exception is /etc : you don't want to null mount it into the jail as it contains very sensible informations like password hashes ; you will have to manually synchronize resolv.conf, localtime, aliases, ... Now with some distance, I must admit that all this gymnastic is quite boring. I now decided to run two virtual hosts as they are managed in a very natural way. These two hosts are just like two real boxes, one running Bind and the other one running Postfix. When I need to update something in the configuration, I login to the box with ssh(1). This take some more memory and in principle no CPU as all processes are sleeping most of the time. BTW, what is the meaning of IMHO? :) It appears very frequently in the mail list. The port games/wtf will translate acronyms for you. %%% obiwan:ports$ wtf IMHO IMHO: in my humble opinion %%% Regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Configuration differences for jails
Now with some distance, I must admit that all this gymnastic is quite boring. I now decided to run two virtual hosts as they are managed in a very natural way. These two hosts are just like two real boxes, one running Bind and the other one running Postfix. When I need to update something in the configuration, I login to the box with ssh(1). This take some more memory and in principle no CPU as all processes are sleeping most of the time. I forgotten to explain that using virtual hosts require some administration too in order to avoid wasting disk space. The jail(8) manual page advices to make world with DESTDIR set. I prefer using null mounts as it doesn't require additional disk space and an upgrade of the host will automagically upgrade virtual hosts. You will nevertheless have to make distribution and distrib-dirs. Here are the directories I advice you to share : /bin /sbin /lib /libexec /usr/bin /usr/sbin /usr/lib /usr/libexec /usr/libdata /usr/share /usr/doc /usr/compat /usr/ports Sharing ports may be more difficult as it may require sharing the port database, but I think it's still possible. -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Configuration differences for jails
* Jeremie Le Hen [EMAIL PROTECTED] [20050420 16:37]:
Now with some distance, I must admit that all this gymnastic is quite
boring. I now decided to run two virtual hosts as they are managed in
a very natural way. These two hosts are just like two real boxes, one
running Bind and the other one running Postfix. When I need to update
something in the configuration, I login to the box with ssh(1). This
take some more memory and in principle no CPU as all processes are
sleeping most of the time.
I forgotten to explain that using virtual hosts require some
administration too in order to avoid wasting disk space. The jail(8)
manual page advices to make world with DESTDIR set. I prefer using
null mounts as it doesn't require additional disk space and an upgrade
of the host will automagically upgrade virtual hosts. You will
nevertheless have to make distribution and distrib-dirs. Here are the
directories I advice you to share :
/bin /sbin /lib /libexec
/usr/bin /usr/sbin /usr/lib /usr/libexec /usr/libdata /usr/share
/usr/doc /usr/compat /usr/ports
I'm trying to untangle myself on this issue. I have different
filesystems for /, /usr, and /usr/local, mounted in unusual places:
504,p0,1$ ls -l /usr{,/X11R6,/local}
lrwxr-xr-x 1 root wheel 18 7 nov 2003 /usr - fs/base/mount/usr/
lrwxr-xr-x 1 root wheel 25 8 nov 2003 /usr/X11R6 -
../../../apps/mount/X11R6
lrwxr-xr-x 1 root wheel 25 18 abr 20:40 /usr/local -
../../../apps/mount/local
I know I want to share /usr, but not /usr/local, and only parts of /. So
I mount_unionfs /fs/base inside the jail:
above:/fs/base/mount on /fs/jaildata/mount/fs/base/mount (unionfs,
local, read-only, noclusterw)
But this way I don't get the automagically upgrade virtual hosts
behaviour I want, since I'm missing /{,s}bin, /lib and /libexec and I
definitely don't want to share /etc.
I don't think it's easy to take /etc/ outside the root fs, but I don't
see how to share /bin or /lib without leaking info.
How do you handle this? What are those distribution targets and how can
I use them?
tks
--
pica
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Configuration differences for jails
I'm trying to untangle myself on this issue. I have different
filesystems for /, /usr, and /usr/local, mounted in unusual places:
504,p0,1$ ls -l /usr{,/X11R6,/local}
lrwxr-xr-x 1 root wheel 18 7 nov 2003 /usr - fs/base/mount/usr/
lrwxr-xr-x 1 root wheel 25 8 nov 2003 /usr/X11R6 -
../../../apps/mount/X11R6
lrwxr-xr-x 1 root wheel 25 18 abr 20:40 /usr/local -
../../../apps/mount/local
I know I want to share /usr, but not /usr/local, and only parts of /. So
I mount_unionfs /fs/base inside the jail:
above:/fs/base/mount on /fs/jaildata/mount/fs/base/mount (unionfs,
local, read-only, noclusterw)
mount_nullfs(8) will mount one directory and all its content onto another
one, but there is no way to exclude one of the subdirectory. You
will instead have to mount each subdirectory you need, not more. One
other way do achieve this is to make a second null mount over the
directory you don't wan't to share (/usr/local) but I'm not aware of
the consequences of such setup in term of performance and stability.
But this way I don't get the automagically upgrade virtual hosts
behaviour I want, since I'm missing /{,s}bin, /lib and /libexec and I
definitely don't want to share /etc.
You won't have a one to one mapping between jail and null mounts. There
are generally multiple null mounts for a unique jail.
Considering your jail root is /jail/test, and you enabled the
jail_$jail_mount (jail_test_mount here) rc.conf(5) variable, here is
the content of /etc/fstab.test :
%%%
/bin/jail/test/bin nullfs ro 0 0
/sbin /jail/test/sbin nullfs ro 0 0
/lib/jail/test/lib nullfs ro 0 0
/libexec/jail/test/libexec nullfs ro 0 0
/usr/bin/jail/test/usr/bin nullfs ro 0 0
/usr/sbin /jail/test/usr/sbin nullfs ro 0 0
/usr/lib/jail/test/usr/lib nullfs ro 0 0
/usr/libexec/jail/test/usr/libexec nullfs ro 0 0
/usr/libdata/jail/test/usr/libdata nullfs ro 0 0
/usr/share /jail/test/usr/sharenullfs ro 0 0
/usr/compat /jail/test/usr/compat nullfs ro 0 0
%%%
I don't think it's easy to take /etc/ outside the root fs, but I don't
see how to share /bin or /lib without leaking info.
How do you handle this? What are those distribution targets and how can
I use them?
As I said above, null mount each directory.
Regards,
--
Jeremie Le Hen
jeremie at le-hen dot org ttz at chchile dot org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
