From bzeeb-lists at lists.zabbadoz.net Tue Sep 1 20:20:07 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Tue Sep 1 20:20:20 2009 Subject: Not getting an IPv6 in a jail In-Reply-To: References: Message-ID: <20090901200313.J68375@maildrop.int.zabbadoz.net> On Tue, 1 Sep 2009, Major Domo wrote: Hi, > Apologies if this has been discussed already but I searched the web > and the mailing lists and haven't found hints on my problem. > > I've got a jail, I assign it a set of IP addresses, and it just won't > take the IP6 I give it. > > > Uname: > FreeBSD 7.2-STABLE > > jail_ns_ip="192.168.0.252,fe80::c0a8:fc" > > jls -v: > JID Hostname Path > Name State > CPUSetID > IP Address(es) > 23 [snip] /var/jail/ns > ALIVE > 2 > 192.168.0.252 > fe80::c0a8:fc > > > ifconfig lo252 from the host: > lo252: flags=8049 metric 0 mtu 16384 > inet 192.168.0.252 netmask 0xffffffff > inet6 fe80::c0a8:fc%lo252 prefixlen 128 scopeid 0x5 > > > ifconfig from the jail: > re0: flags=8843 metric 0 mtu 1500 > options=389b > ether 00:e0:f4:19:e9:d2 > media: Ethernet autoselect (100baseTX ) > status: active > lo0: flags=8049 metric 0 mtu 16384 > pflog0: flags=141 metric 0 mtu 33204 > lo252: flags=8049 metric 0 mtu 16384 > inet 192.168.0.252 netmask 0xffffffff This is a rather special case. For link-local addresses you have to give the scope as well but it won't take the scope with the %lo252 notation but only in the KAME in-kernel syntax I would assume. Can you try: jail_ns_ip="192.168.0.252,fe80:5::c0a8:fc" Note the added 5 in the second group of hex digits. That five is the interface index. I took it from the "scopeid 0x5". In case your interface index changes you will need to adjust the address. I cannot say if it'll work but it would be worth a try. /bz -- Bjoern A. Zeeb What was I talking about and who are you again? From ml-SPAM at my.gd Wed Sep 2 16:21:20 2009 From: ml-SPAM at my.gd (FLEURIOT Damien) Date: Wed Sep 2 16:21:32 2009 Subject: Not getting an IPv6 in a jail In-Reply-To: <20090901200313.J68375@maildrop.int.zabbadoz.net> References: <20090901200313.J68375@maildrop.int.zabbadoz.net> Message-ID: <20090902160440.GA28417@sd-13813.dedibox.fr> On Tue, Sep 01, 2009 at 08:15:24PM +0000 or thereabouts, Bjoern A. Zeeb wrote: > On Tue, 1 Sep 2009, Major Domo wrote: > > Hi, > > >Apologies if this has been discussed already but I searched the web > >and the mailing lists and haven't found hints on my problem. > > > >I've got a jail, I assign it a set of IP addresses, and it just won't > >take the IP6 I give it. > > > > > >Uname: > >FreeBSD 7.2-STABLE > > > >jail_ns_ip="192.168.0.252,fe80::c0a8:fc" > > > >jls -v: > > JID Hostname Path > > Name State > > CPUSetID > > IP Address(es) > > 23 [snip] /var/jail/ns > > ALIVE > > 2 > > 192.168.0.252 > > fe80::c0a8:fc > > > > > >ifconfig lo252 from the host: > >lo252: flags=8049 metric 0 mtu 16384 > > inet 192.168.0.252 netmask 0xffffffff > > inet6 fe80::c0a8:fc%lo252 prefixlen 128 scopeid 0x5 > > > > > >ifconfig from the jail: > >re0: flags=8843 metric 0 mtu 1500 > > options=389b > > ether 00:e0:f4:19:e9:d2 > > media: Ethernet autoselect (100baseTX ) > > status: active > >lo0: flags=8049 metric 0 mtu 16384 > >pflog0: flags=141 metric 0 mtu 33204 > >lo252: flags=8049 metric 0 mtu 16384 > > inet 192.168.0.252 netmask 0xffffffff > > > This is a rather special case. For link-local addresses you have to > give the scope as well but it won't take the scope with the %lo252 > notation but only in the KAME in-kernel syntax I would assume. > Can you try: > > jail_ns_ip="192.168.0.252,fe80:5::c0a8:fc" > > Note the added 5 in the second group of hex digits. That five is the > interface index. I took it from the "scopeid 0x5". In case your > interface index changes you will need to adjust the address. > > I cannot say if it'll work but it would be worth a try. > > /bz > > -- > Bjoern A. Zeeb What was I talking about and who are you again? Hi list, Bjoern, John, I confirm it is now working with the following line in /etc/rc.conf: jail_ns_ip="192.168.0.252,fec0:5::df:252" along with redirections in /etc/pf.conf: rdr pass log on $ext_if inet proto {tcp,udp} to $ext_if port 53 -> $lo252_if port 53 rdr pass log on $ext_if inet6 proto {tcp,udp} to $ext_if port 53 -> $lo252_if port 53 Notice the use of both the interface's index and a site-local ip6 address instead of the old fe80 as suggested. BIND's now happily running in its jail and responding to public queries. Perhaps a small addition to the jails entry in the Handbook to advise people about the use of IP6 addresses on loopback interfaces would be warranted ? I realize how lousy it is to NAT IP6 but my host assigns only 1 IP6 address per server. Thanks for the help ! Regards -- Damien From dougb at FreeBSD.org Wed Sep 2 16:36:08 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Wed Sep 2 16:36:19 2009 Subject: Not getting an IPv6 in a jail In-Reply-To: <20090902160440.GA28417@sd-13813.dedibox.fr> References: <20090901200313.J68375@maildrop.int.zabbadoz.net> <20090902160440.GA28417@sd-13813.dedibox.fr> Message-ID: <4A9E98AD.1070202@FreeBSD.org> FLEURIOT Damien wrote: > BIND's now happily running in its jail and responding to public > queries. It's up to you if you choose to do it, but there is no reason to run BIND in a jail. The chroot feature provided by default by rc.d/named is quite adequate security. Doug -- This .signature sanitized for your protection From marka at isc.org Wed Sep 2 23:04:36 2009 From: marka at isc.org (Mark Andrews) Date: Wed Sep 2 23:04:42 2009 Subject: Not getting an IPv6 in a jail In-Reply-To: Your message of "Wed, 02 Sep 2009 18:04:42 +0200." <20090902160440.GA28417@sd-13813.dedibox.fr> References: <20090901200313.J68375@maildrop.int.zabbadoz.net> <20090902160440.GA28417@sd-13813.dedibox.fr> Message-ID: <200909022304.n82N4PHe079957@drugs.dv.isc.org> In message <20090902160440.GA28417@sd-13813.dedibox.fr>, FLEURIOT Damien writes : > On Tue, Sep 01, 2009 at 08:15:24PM +0000 or thereabouts, Bjoern A. Zeeb wrote > : > > On Tue, 1 Sep 2009, Major Domo wrote: > > > > Hi, > > > > >Apologies if this has been discussed already but I searched the web > > >and the mailing lists and haven't found hints on my problem. > > > > > >I've got a jail, I assign it a set of IP addresses, and it just won't > > >take the IP6 I give it. > > > > > > > > >Uname: > > >FreeBSD 7.2-STABLE > > > > > >jail_ns_ip="192.168.0.252,fe80::c0a8:fc" > > > > > >jls -v: > > > JID Hostname Path > > > Name State > > > CPUSetID > > > IP Address(es) > > > 23 [snip] /var/jail/ns > > > ALIVE > > > 2 > > > 192.168.0.252 > > > fe80::c0a8:fc > > > > > > > > >ifconfig lo252 from the host: > > >lo252: flags=8049 metric 0 mtu 16384 > > > inet 192.168.0.252 netmask 0xffffffff > > > inet6 fe80::c0a8:fc%lo252 prefixlen 128 scopeid 0x5 > > > > > > > > >ifconfig from the jail: > > >re0: flags=8843 metric 0 mtu 1500 > > > options=389b UCAST,WOL_MCAST,WOL_MAGIC> > > > ether 00:e0:f4:19:e9:d2 > > > media: Ethernet autoselect (100baseTX ) > > > status: active > > >lo0: flags=8049 metric 0 mtu 16384 > > >pflog0: flags=141 metric 0 mtu 33204 > > >lo252: flags=8049 metric 0 mtu 16384 > > > inet 192.168.0.252 netmask 0xffffffff > > > > > > This is a rather special case. For link-local addresses you have to > > give the scope as well but it won't take the scope with the %lo252 > > notation but only in the KAME in-kernel syntax I would assume. > > Can you try: > > > > jail_ns_ip="192.168.0.252,fe80:5::c0a8:fc" > > > > Note the added 5 in the second group of hex digits. That five is the > > interface index. I took it from the "scopeid 0x5". In case your > > interface index changes you will need to adjust the address. > > > > I cannot say if it'll work but it would be worth a try. > > > > /bz > > > > -- > > Bjoern A. Zeeb What was I talking about and who are you again? > > > Hi list, Bjoern, John, > > > I confirm it is now working with the following line in /etc/rc.conf: > jail_ns_ip="192.168.0.252,fec0:5::df:252" > > along with redirections in /etc/pf.conf: > rdr pass log on $ext_if inet proto {tcp,udp} to $ext_if port 53 -> > $lo252_if port 53 > rdr pass log on $ext_if inet6 proto {tcp,udp} to $ext_if port 53 -> > $lo252_if port 53 > > > Notice the use of both the interface's index and a site-local ip6 > address instead of the old fe80 as suggested. > > BIND's now happily running in its jail and responding to public > queries. > > > Perhaps a small addition to the jails entry in the Handbook to > advise people about the use of IP6 addresses on loopback interfaces > would be warranted ? > > I realize how lousy it is to NAT IP6 but my host assigns only 1 > IP6 address per server. Then complain. There is no reason to be miserly with IPv6 addresses. > Thanks for the help ! > > Regards > > -- > Damien > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From spry at anarchy.in.the.ph Thu Sep 3 05:59:05 2009 From: spry at anarchy.in.the.ph (Mars G Miro) Date: Thu Sep 3 05:59:16 2009 Subject: Not getting an IPv6 in a jail In-Reply-To: <200909022304.n82N4PHe079957@drugs.dv.isc.org> References: <20090901200313.J68375@maildrop.int.zabbadoz.net> <20090902160440.GA28417@sd-13813.dedibox.fr> <200909022304.n82N4PHe079957@drugs.dv.isc.org> Message-ID: On Thu, Sep 3, 2009 at 7:04 AM, Mark Andrews wrote: > > In message <20090902160440.GA28417@sd-13813.dedibox.fr>, FLEURIOT Damien writes > : >> On Tue, Sep 01, 2009 at 08:15:24PM +0000 or thereabouts, Bjoern A. Zeeb wrote >> : >> > On Tue, 1 Sep 2009, Major Domo wrote: >> > >> > Hi, >> > >> > >Apologies if this has been discussed already but I searched the web >> > >and the mailing lists and haven't found hints on my problem. >> > > >> > >I've got a jail, I assign it a set of IP addresses, and it just won't >> > >take the IP6 I give it. >> > > >> > > >> > >Uname: >> > >FreeBSD 7.2-STABLE >> > > >> > >jail_ns_ip="192.168.0.252,fe80::c0a8:fc" >> > > >> > >jls -v: >> > > ?JID ?Hostname ? ? ? ? ? ? ? ? ? ? ?Path >> > > ? ? ? Name ? ? ? ? ? ? ? ? ? ? ? ? ?State >> > > ? ? ? CPUSetID >> > > ? ? ? IP Address(es) >> > > ? 23 ?[snip] ? ? ? ? ? ? ? ? ? ? ?/var/jail/ns >> > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ALIVE >> > > ? ? ? 2 >> > > ? ? ? 192.168.0.252 >> > > ? ? ? fe80::c0a8:fc >> > > >> > > >> > >ifconfig lo252 from the host: >> > >lo252: flags=8049 metric 0 mtu 16384 >> > > ? ? ? inet 192.168.0.252 netmask 0xffffffff >> > > ? ? ? inet6 fe80::c0a8:fc%lo252 prefixlen 128 scopeid 0x5 >> > > >> > > >> > >ifconfig from the jail: >> > >re0: flags=8843 metric 0 mtu 1500 >> > > ? ? ? options=389b> UCAST,WOL_MCAST,WOL_MAGIC> >> > > ? ? ? ether 00:e0:f4:19:e9:d2 >> > > ? ? ? media: Ethernet autoselect (100baseTX ) >> > > ? ? ? status: active >> > >lo0: flags=8049 metric 0 mtu 16384 >> > >pflog0: flags=141 metric 0 mtu 33204 >> > >lo252: flags=8049 metric 0 mtu 16384 >> > > ? ? ? inet 192.168.0.252 netmask 0xffffffff >> > >> > >> > This is a rather special case. ?For link-local addresses you have to >> > give the scope as well but it won't take the scope with the %lo252 >> > notation but only in the KAME in-kernel syntax I would assume. >> > Can you try: >> > >> > jail_ns_ip="192.168.0.252,fe80:5::c0a8:fc" >> > >> > Note the added 5 in the second group of hex digits. ?That five is the >> > interface index. ?I took it from the "scopeid 0x5". In case your >> > interface index changes you will need to adjust the address. >> > >> > I cannot say if it'll work but it would be worth a try. >> > >> > /bz >> > >> > -- >> > Bjoern A. Zeeb ? ? ? ? ? What was I talking about and who are you again? >> >> >> Hi list, Bjoern, John, >> >> >> I confirm it is now working with the following line in /etc/rc.conf: >> jail_ns_ip="192.168.0.252,fec0:5::df:252" >> >> along with redirections in /etc/pf.conf: >> rdr pass log on $ext_if inet proto {tcp,udp} to $ext_if port 53 -> >> $lo252_if port 53 >> rdr pass log on $ext_if inet6 proto {tcp,udp} to $ext_if port 53 -> >> $lo252_if port 53 >> >> >> Notice the use of both the interface's index and a site-local ip6 >> address instead of the old fe80 as suggested. >> >> BIND's now happily running in its jail and responding to public >> queries. >> >> >> Perhaps a small addition to the jails entry in the Handbook to >> advise people about the use of IP6 addresses on loopback interfaces >> would be warranted ? >> >> I realize how lousy it is to NAT IP6 but my host assigns only 1 >> IP6 address per server. > > Then complain. ?There is no reason to be miserly with IPv6 addresses. > True that. Or just sign up @HE. They can give you up to 4 tunnels w/ a /64 and a /48 (if you opt) for each of these 4 tunnels! All you hafta do is give them your contact info and a public IPv4 and it doesn't hafta be static --- there are tools to update their records.. >> Thanks for the help ! >> >> Regards >> >> -- >> Damien >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 ? ? ? ? ? ? ? ? INTERNET: marka@isc.org > _______________________________________________ > freebsd-jail@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-jail > To unsubscribe, send any mail to "freebsd-jail-unsubscribe@freebsd.org" > -- cheers mars ----- Marie von Ebner-Eschenbach - "Even a stopped clock is right twice a day." - http://www.brainyquote.com/quotes/authors/m/marie_von_ebnereschenbac.html From jhb at freebsd.org Thu Sep 3 12:21:40 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Sep 3 12:21:54 2009 Subject: Not getting an IPv6 in a jail In-Reply-To: <4A9E98AD.1070202@FreeBSD.org> References: <20090902160440.GA28417@sd-13813.dedibox.fr> <4A9E98AD.1070202@FreeBSD.org> Message-ID: <200909030808.08440.jhb@freebsd.org> On Wednesday 02 September 2009 12:09:17 pm Doug Barton wrote: > FLEURIOT Damien wrote: > > > BIND's now happily running in its jail and responding to public > > queries. > > It's up to you if you choose to do it, but there is no reason to run > BIND in a jail. The chroot feature provided by default by rc.d/named > is quite adequate security. That is debatable. One of the chief benefits of a jail is that if a server is compromised so that an attacker can gain root access that root access is limited in what it can do compared to a simple chroot. That is true for any server you would run under a jail, not just BIND. -- John Baldwin From bugmaster at FreeBSD.org Mon Sep 7 11:07:03 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 7 11:08:50 2009 Subject: Current problem reports assigned to freebsd-jail@FreeBSD.org Message-ID: <200909071107.n87B72B0010284@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/133265 jail [jail] is there a solution how to run nfs client in ja o kern/119842 jail [smbfs] [jail] "Bad address" with smbfs inside a jail o bin/99566 jail [jail] [patch] fstat(1) according to specified jid o bin/32828 jail [jail] w(1) incorrectly handles stale utmp slots with 4 problems total. From dougb at FreeBSD.org Tue Sep 8 18:27:57 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Sep 8 18:28:09 2009 Subject: Not getting an IPv6 in a jail In-Reply-To: <200909030808.08440.jhb@freebsd.org> References: <20090902160440.GA28417@sd-13813.dedibox.fr> <4A9E98AD.1070202@FreeBSD.org> <200909030808.08440.jhb@freebsd.org> Message-ID: <4AA6A22B.1070402@FreeBSD.org> John Baldwin wrote: > On Wednesday 02 September 2009 12:09:17 pm Doug Barton wrote: >> FLEURIOT Damien wrote: >> >>> BIND's now happily running in its jail and responding to public >>> queries. >> It's up to you if you choose to do it, but there is no reason to run >> BIND in a jail. The chroot feature provided by default by rc.d/named >> is quite adequate security. > > That is debatable. One of the chief benefits of a jail is that if a server is > compromised so that an attacker can gain root access that root access is > limited in what it can do compared to a simple chroot. That is true for any > server you would run under a jail, not just BIND. On a strictly intellectual level I agree that jails are in some ways more limited than chroots. OTOH, named chroots by default into /var/named which has no binaries at all. The most "interesting" things in the chroot environment are /dev/null and /dev/random. Jails by nature have a more or less complete FreeBSD system available to the attacker. Also, in addition to being chroot'ed named runs by default as user 'bind' which is rather limited in what it can modify in the chroot. I realize that it's theoretically possible for an attacker to break out of a chroot environment, escalate their privileges, etc. I suppose my point is that if you're looking for things to tighten down on a FreeBSD system the default named configuration is not the first place I'd look. :) Doug From bugmaster at FreeBSD.org Mon Sep 14 11:07:04 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 14 11:08:37 2009 Subject: Current problem reports assigned to freebsd-jail@FreeBSD.org Message-ID: <200909141107.n8EB72N5072385@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/133265 jail [jail] is there a solution how to run nfs client in ja o kern/119842 jail [smbfs] [jail] "Bad address" with smbfs inside a jail o bin/99566 jail [jail] [patch] fstat(1) according to specified jid o bin/32828 jail [jail] w(1) incorrectly handles stale utmp slots with 4 problems total. From greenx at yartv.ru Fri Sep 18 06:21:56 2009 From: greenx at yartv.ru (Andrey Groshev) Date: Fri Sep 18 06:22:32 2009 Subject: df output into jail Message-ID: <4AB324F5.3040106@yartv.ru> Hi, All! I create garbage files. Mounted in the main system partition for data. #mount|grep /usr/jails/samba/ /dev/amrd0s4d.journal on /usr/jails/samba/data (ufs, asynchronous, local, noatime, nosuid, gjournal) /usr/jails/basejail on /usr/jails/samba/basejail (nullfs, local, read-only) devfs on /usr/jails/samba/dev (devfs, local) fdescfs on /usr/jails/samba/dev/fd (fdescfs) procfs on /usr/jails/samba/proc (procfs, local) And now... I see the output in the Jail "df-h" - it returns only the root mount. # df -h Filesystem Size Used Avail Capacity Mounted on /dev/amrd0s4a 18G 3.6G 13G 21% / If you ask specifically "df-h / data", then displays the desired data. # df -h /data Filesystem Size Used Avail Capacity Mounted on /dev/amrd0s4d.journal 178G 768M 163G 0% [restricted] Looking sources, decided that this is due to answer "mount". IMHO, should be able to see the file systems mounted below the directory of jail. From 000.fbsd at quip.cz Fri Sep 18 08:37:39 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Fri Sep 18 08:37:46 2009 Subject: df output into jail In-Reply-To: <4AB324F5.3040106@yartv.ru> References: <4AB324F5.3040106@yartv.ru> Message-ID: <4AB34259.4010204@quip.cz> Andrey Groshev wrote: > Hi, All! > > I create garbage files. > Mounted in the main system partition for data. > > #mount|grep /usr/jails/samba/ > /dev/amrd0s4d.journal on /usr/jails/samba/data (ufs, asynchronous, > local, noatime, nosuid, gjournal) > /usr/jails/basejail on /usr/jails/samba/basejail (nullfs, local, read-only) > devfs on /usr/jails/samba/dev (devfs, local) > fdescfs on /usr/jails/samba/dev/fd (fdescfs) > procfs on /usr/jails/samba/proc (procfs, local) > > > And now... > I see the output in the Jail "df-h" - it returns only the root mount. > > # df -h > Filesystem Size Used Avail Capacity Mounted on > /dev/amrd0s4a 18G 3.6G 13G 21% / > > If you ask specifically "df-h / data", then displays the desired data. > > # df -h /data > Filesystem Size Used Avail Capacity Mounted on > /dev/amrd0s4d.journal 178G 768M 163G 0% [restricted] > > Looking sources, decided that this is due to answer "mount". > IMHO, should be able to see the file systems mounted below the directory > of jail. I think you are looking for security.jail.enforce_statfs=1 Default is security.jail.enforce_statfs=2! See man jail(8) for more details. Miroslav Lachman From greenx at yartv.ru Mon Sep 21 05:17:56 2009 From: greenx at yartv.ru (Andrey Groshev) Date: Mon Sep 21 05:18:03 2009 Subject: df output into jail In-Reply-To: <4AB34259.4010204@quip.cz> References: <4AB324F5.3040106@yartv.ru> <4AB34259.4010204@quip.cz> Message-ID: <4AB70C75.6000609@yartv.ru> Miroslav Lachman ?????: > Andrey Groshev wrote: >> Hi, All! >> >> I create garbage files. >> Mounted in the main system partition for data. >> >> #mount|grep /usr/jails/samba/ >> /dev/amrd0s4d.journal on /usr/jails/samba/data (ufs, asynchronous, >> local, noatime, nosuid, gjournal) >> /usr/jails/basejail on /usr/jails/samba/basejail (nullfs, local, >> read-only) >> devfs on /usr/jails/samba/dev (devfs, local) >> fdescfs on /usr/jails/samba/dev/fd (fdescfs) >> procfs on /usr/jails/samba/proc (procfs, local) >> >> >> And now... >> I see the output in the Jail "df-h" - it returns only the root mount. >> >> # df -h >> Filesystem Size Used Avail Capacity Mounted on >> /dev/amrd0s4a 18G 3.6G 13G 21% / >> >> If you ask specifically "df-h / data", then displays the desired data. >> >> # df -h /data >> Filesystem Size Used Avail Capacity Mounted on >> /dev/amrd0s4d.journal 178G 768M 163G 0% [restricted] >> >> Looking sources, decided that this is due to answer "mount". >> IMHO, should be able to see the file systems mounted below the >> directory of jail. > > I think you are looking for security.jail.enforce_statfs=1 > Default is security.jail.enforce_statfs=2! > > See man jail(8) for more details. > > Miroslav Lachman Yes, this is it! I'm sorry that I did not read the full manual. From bugmaster at FreeBSD.org Mon Sep 21 11:06:59 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 21 11:08:40 2009 Subject: Current problem reports assigned to freebsd-jail@FreeBSD.org Message-ID: <200909211106.n8LB6wZ2030309@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/133265 jail [jail] is there a solution how to run nfs client in ja o kern/119842 jail [smbfs] [jail] "Bad address" with smbfs inside a jail o bin/99566 jail [jail] [patch] fstat(1) according to specified jid o bin/32828 jail [jail] w(1) incorrectly handles stale utmp slots with 4 problems total. From bugmaster at FreeBSD.org Mon Sep 28 11:06:58 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 28 11:08:34 2009 Subject: Current problem reports assigned to freebsd-jail@FreeBSD.org Message-ID: <200909281106.n8SB6vfL064064@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/133265 jail [jail] is there a solution how to run nfs client in ja o kern/119842 jail [smbfs] [jail] "Bad address" with smbfs inside a jail o bin/99566 jail [jail] [patch] fstat(1) according to specified jid o bin/32828 jail [jail] w(1) incorrectly handles stale utmp slots with 4 problems total. From edwin.shao at gmail.com Mon Sep 28 12:31:18 2009 From: edwin.shao at gmail.com (Edwin Shao) Date: Mon Sep 28 12:31:24 2009 Subject: Tutorial for Hierarchical Jails? Message-ID: Hello, Does anyone have a walkthrough for how to get hierarchical jails to work? I've been playing around with it for a couple of days and it simply is not working. I would like to know if anyone has gotten it to work, and if so, how? The error I tend to get within a jail (starting another child jail) is: hyper# ./jail start Configuring jails:. Starting jails: cannot start jail "neko": I'm using very basic steps as outlined in < http://www.freebsd.org/doc/en/books/handbook/jails-intro.html> and I am easily getting the jails to work in the non-jailed highest level system. What I have done to troubleshoot so far: * Installed from scratch 8.0-RC1 ISO, make buildworld from scratch 8.0-RC1 /usr/src. * Created very liberal sysctls. * Tried different combinations of disabling/enabling mounted systems such as devfs, procfs, etc. * Tried modifying different module fs to enable the "jail" flag. This is under a clean install of 8.0-RC1. I'd be happy to provide additional information for troubleshooting, but I'm not even sure what's going wrong. It'd probably be more helpful for you to just let me know what you did to get it wroking. Thanks, Edwin From jamie at FreeBSD.org Mon Sep 28 16:35:57 2009 From: jamie at FreeBSD.org (Jamie Gritton) Date: Mon Sep 28 16:36:03 2009 Subject: Tutorial for Hierarchical Jails? In-Reply-To: References: Message-ID: <4AC0E5E6.1010700@FreeBSD.org> Edwin Shao wrote: > Hello, > Does anyone have a walkthrough for how to get hierarchical jails to work? > I've been playing around with it for a couple of days and it simply is not > working. I would like to know if anyone has gotten it to work, and if so, > how? > > The error I tend to get within a jail (starting another child jail) is: > hyper# ./jail start > Configuring jails:. > Starting jails: cannot start jail "neko": > > I'm using very basic steps as outlined in < > http://www.freebsd.org/doc/en/books/handbook/jails-intro.html> and I am > easily getting the jails to work in the non-jailed highest level system. > > What I have done to troubleshoot so far: > * Installed from scratch 8.0-RC1 ISO, make buildworld from scratch 8.0-RC1 > /usr/src. > * Created very liberal sysctls. > * Tried different combinations of disabling/enabling mounted systems such as > devfs, procfs, etc. > * Tried modifying different module fs to enable the "jail" flag. > > This is under a clean install of 8.0-RC1. I'd be happy to provide additional > information for troubleshooting, but I'm not even sure what's going wrong. > It'd probably be more helpful for you to just let me know what you did to > get it wroking. The main thing you need to do is to set the first-level jail's children.max parameter. It defaults to zero, which doesn't allow a jail to create any child jails (the non-hierarchical default). It sounds like you have everything else you need. - Jamie From edwin.shao at gmail.com Mon Sep 28 17:46:12 2009 From: edwin.shao at gmail.com (Edwin Shao) Date: Mon Sep 28 17:46:19 2009 Subject: Tutorial for Hierarchical Jails? In-Reply-To: <4AC0E5E6.1010700@FreeBSD.org> References: <4AC0E5E6.1010700@FreeBSD.org> Message-ID: Hi Jamie, When I try to change the parameter, nothing happens: rescue /etc> sudo sysctl security.jail.param.children.max=1 security.jail.param.children.max: 0 -> 0 rescue /etc> sudo sysctl security.jail.param.children.max security.jail.param.children.max: 0 Am I doing this incorrectly? Thanks, Edwin On Mon, Sep 28, 2009 at 7:35 PM, Jamie Gritton wrote: > Edwin Shao wrote: > >> Hello, >> Does anyone have a walkthrough for how to get hierarchical jails to work? >> I've been playing around with it for a couple of days and it simply is not >> working. I would like to know if anyone has gotten it to work, and if so, >> how? >> >> The error I tend to get within a jail (starting another child jail) is: >> hyper# ./jail start >> Configuring jails:. >> Starting jails: cannot start jail "neko": >> >> I'm using very basic steps as outlined in < >> http://www.freebsd.org/doc/en/books/handbook/jails-intro.html> and I am >> easily getting the jails to work in the non-jailed highest level system. >> >> What I have done to troubleshoot so far: >> * Installed from scratch 8.0-RC1 ISO, make buildworld from scratch 8.0-RC1 >> /usr/src. >> * Created very liberal sysctls. >> * Tried different combinations of disabling/enabling mounted systems such >> as >> devfs, procfs, etc. >> * Tried modifying different module fs to enable the "jail" flag. >> >> This is under a clean install of 8.0-RC1. I'd be happy to provide >> additional >> information for troubleshooting, but I'm not even sure what's going wrong. >> It'd probably be more helpful for you to just let me know what you did to >> get it wroking. >> > > The main thing you need to do is to set the first-level jail's > children.max parameter. It defaults to zero, which doesn't allow a jail > to create any child jails (the non-hierarchical default). It sounds > like you have everything else you need. > > - Jamie > From jamie at FreeBSD.org Mon Sep 28 18:13:16 2009 From: jamie at FreeBSD.org (Jamie Gritton) Date: Mon Sep 28 18:13:22 2009 Subject: Tutorial for Hierarchical Jails? In-Reply-To: References: <4AC0E5E6.1010700@FreeBSD.org> Message-ID: <4AC0FCB5.2050009@FreeBSD.org> Edwin Shao wrote: > When I try to change the parameter, nothing happens: > rescue /etc> sudo sysctl security.jail.param.children.max=1 > security.jail.param.children.max: 0 -> 0 > > rescue /etc> sudo sysctl security.jail.param.children.max > security.jail.param.children.max: 0 > > Am I doing this incorrectly? Yes. Use jail(8) to set the parameters, not sysctl. The security.jail.param.* sysctls are for reference only and have no useful values to get or set. Set it with: jail -m jid= children.max=1 Run this on the base system, i.e. not inside the jail in question. - Jamie From bzeeb-lists at lists.zabbadoz.net Mon Sep 28 18:13:32 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Mon Sep 28 18:13:38 2009 Subject: Tutorial for Hierarchical Jails? In-Reply-To: References: <4AC0E5E6.1010700@FreeBSD.org> Message-ID: <20090928180731.M68375@maildrop.int.zabbadoz.net> On Mon, 28 Sep 2009, Edwin Shao wrote: > Hi Jamie, > When I try to change the parameter, nothing happens: > rescue /etc> sudo sysctl security.jail.param.children.max=1 > security.jail.param.children.max: 0 -> 0 > > rescue /etc> sudo sysctl security.jail.param.children.max > security.jail.param.children.max: 0 > > Am I doing this incorrectly? Yes. It's a parameter to jail(8). The security.jail.param sysctls can be seen as a list of possible options valid to jail(8). See man 8 jail for the exact details. /bz -- Bjoern A. Zeeb What was I talking about and who are you again? From edwin.shao at gmail.com Mon Sep 28 20:26:21 2009 From: edwin.shao at gmail.com (Edwin Shao) Date: Mon Sep 28 20:26:27 2009 Subject: Tutorial for Hierarchical Jails? In-Reply-To: <20090928180731.M68375@maildrop.int.zabbadoz.net> References: <4AC0E5E6.1010700@FreeBSD.org> <20090928180731.M68375@maildrop.int.zabbadoz.net> Message-ID: Thanks, that worked for me. * Using jail to change children.max on the parent does not affect `sysctl security.jail.param.children.max` in the child. Also security.jail.param.children.cur never changes either. Not sure if that's intended behavior. * Is there any way to persist the security.jail.param.children.max parameter without entering the jail command every time? * I get the following output when I create a jail inside a jail: hyper ~> ezjail-admin start neko Configuring jails:. Starting jails:devfs rule: ioctl DEVFSIO_RGETNEXT: Operation not permitted devfs rule: ioctl DEVFSIO_RGETNEXT: Operation not permitted /etc/rc.d/jail: WARNING: devfs_set_ruleset: you must specify a ruleset number devfs rule: ioctl DEVFSIO_SAPPLY: Operation not permitted ln: log: Operation not permitted mount: proc : Operation not permitted neko. I'm using the same configuration values as in the parent's jail, which work. Everything seems to work alright inside the jail, so I assume the errors are safe to ignore? Thanks again! - Edwin On Mon, Sep 28, 2009 at 9:11 PM, Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > On Mon, 28 Sep 2009, Edwin Shao wrote: > > Hi Jamie, >> When I try to change the parameter, nothing happens: >> rescue /etc> sudo sysctl security.jail.param.children.max=1 >> security.jail.param.children.max: 0 -> 0 >> >> rescue /etc> sudo sysctl security.jail.param.children.max >> security.jail.param.children.max: 0 >> >> Am I doing this incorrectly? >> > > Yes. It's a parameter to jail(8). The security.jail.param sysctls can > be seen as a list of possible options valid to jail(8). See man 8 jail > for the exact details. > > /bz > > -- > Bjoern A. Zeeb What was I talking about and who are you again? > From jamie at FreeBSD.org Mon Sep 28 21:16:15 2009 From: jamie at FreeBSD.org (Jamie Gritton) Date: Mon Sep 28 21:16:25 2009 Subject: Tutorial for Hierarchical Jails? In-Reply-To: References: <4AC0E5E6.1010700@FreeBSD.org> <20090928180731.M68375@maildrop.int.zabbadoz.net> Message-ID: <4AC12798.8070308@FreeBSD.org> The sysctls not only don't get written to, they don't have any useful information to read either. They only describe the existence and format of the various jail parameters. Sorry, but there;s no way to set a default children.max parameter or inherit it from the parent. We've decided to set the default to the most secure/restrictive in many cases. Once we've come up with a new jail configuration interface, this won't be such a hassle. The devfs errors are probably something that will have to be addressed in a later revision - I haven't looked in the devfs direction so I'm not sure about that. The mount error may be related to the first jail's allow.mount parameter (whose default comes from security.jail.mount_allowed). - Jamie Edwin Shao wrote: > Thanks, that worked for me. > > * Using jail to change children.max on the parent does not affect > `sysctl security.jail.param.children.max` in the child. Also > security.jail.param.children.cur never changes either. Not sure if > that's intended behavior. > * Is there any way to persist the security.jail.param.children.max > parameter without entering the jail command every time? > * I get the following output when I create a jail inside a jail: > > hyper ~> ezjail-admin start neko > Configuring jails:. > Starting jails:devfs rule: ioctl DEVFSIO_RGETNEXT: Operation not permitted > devfs rule: ioctl DEVFSIO_RGETNEXT: Operation not permitted > /etc/rc.d/jail: WARNING: devfs_set_ruleset: you must specify a ruleset > number > devfs rule: ioctl DEVFSIO_SAPPLY: Operation not permitted > ln: log: Operation not permitted > mount: proc : Operation not permitted > neko. > > I'm using the same configuration values as in the parent's jail, which > work. Everything seems to work alright inside the jail, so I assume the > errors are safe to ignore? > > Thanks again! > - Edwin > > On Mon, Sep 28, 2009 at 9:11 PM, Bjoern A. Zeeb > > > wrote: > > On Mon, 28 Sep 2009, Edwin Shao wrote: > > Hi Jamie, > When I try to change the parameter, nothing happens: > rescue /etc> sudo sysctl security.jail.param.children.max=1 > security.jail.param.children.max: 0 -> 0 > > rescue /etc> sudo sysctl security.jail.param.children.max > security.jail.param.children.max: 0 > > Am I doing this incorrectly? > > > Yes. It's a parameter to jail(8). The security.jail.param sysctls can > be seen as a list of possible options valid to jail(8). See man 8 jail > for the exact details. > > /bz > > -- > Bjoern A. Zeeb What was I talking about and who are you again? > > From edwin.shao at gmail.com Tue Sep 29 00:07:55 2009 From: edwin.shao at gmail.com (Edwin Shao) Date: Tue Sep 29 00:08:02 2009 Subject: Tutorial for Hierarchical Jails? In-Reply-To: <4AC12798.8070308@FreeBSD.org> References: <4AC0E5E6.1010700@FreeBSD.org> <20090928180731.M68375@maildrop.int.zabbadoz.net> <4AC12798.8070308@FreeBSD.org> Message-ID: One other thing that is odd: hierarchical jails don't seem to inherit some sysctls such as allow_raw_socket. In the host (jail), rc.conf has jail_set_allow_raw_sockets="YES" and sysctl.conf has "security.jail.allow_raw_sockets=1", but no child jail can ping out: neko# ping google.com ping: socket: Operation not permitted What is happening in this case? Thank you for your time again. On Tue, Sep 29, 2009 at 12:16 AM, Jamie Gritton wrote: > The sysctls not only don't get written to, they don't have any useful > information to read either. They only describe the existence and format > of the various jail parameters. Sorry, but there;s no way to set a > default children.max parameter or inherit it from the parent. We've > decided to set the default to the most secure/restrictive in many cases. > Once we've come up with a new jail configuration interface, this won't > be such a hassle. > > The devfs errors are probably something that will have to be addressed > in a later revision - I haven't looked in the devfs direction so I'm not > sure about that. The mount error may be related to the first jail's > allow.mount parameter (whose default comes from > security.jail.mount_allowed). > > - Jamie > > Edwin Shao wrote: > >> Thanks, that worked for me. >> >> * Using jail to change children.max on the parent does not affect `sysctl >> security.jail.param.children.max` in the child. Also >> security.jail.param.children.cur never changes either. Not sure if that's >> intended behavior. >> * Is there any way to persist the security.jail.param.children.max >> parameter without entering the jail command every time? * I get the >> following output when I create a jail inside a jail: >> >> hyper ~> ezjail-admin start neko >> Configuring jails:. >> Starting jails:devfs rule: ioctl DEVFSIO_RGETNEXT: Operation not permitted >> devfs rule: ioctl DEVFSIO_RGETNEXT: Operation not permitted >> /etc/rc.d/jail: WARNING: devfs_set_ruleset: you must specify a ruleset >> number >> devfs rule: ioctl DEVFSIO_SAPPLY: Operation not permitted >> ln: log: Operation not permitted >> mount: proc : Operation not permitted >> neko. >> >> I'm using the same configuration values as in the parent's jail, which >> work. Everything seems to work alright inside the jail, so I assume the >> errors are safe to ignore? >> >> Thanks again! >> - Edwin >> >> On Mon, Sep 28, 2009 at 9:11 PM, Bjoern A. Zeeb < >> bzeeb-lists@lists.zabbadoz.net > >> wrote: >> >> On Mon, 28 Sep 2009, Edwin Shao wrote: >> >> Hi Jamie, >> When I try to change the parameter, nothing happens: >> rescue /etc> sudo sysctl security.jail.param.children.max=1 >> security.jail.param.children.max: 0 -> 0 >> >> rescue /etc> sudo sysctl security.jail.param.children.max >> security.jail.param.children.max: 0 >> >> Am I doing this incorrectly? >> >> >> Yes. It's a parameter to jail(8). The security.jail.param sysctls can >> be seen as a list of possible options valid to jail(8). See man 8 jail >> for the exact details. >> >> /bz >> >> -- Bjoern A. Zeeb What was I talking about and who are you >> again? >> >> >> From jamie at FreeBSD.org Tue Sep 29 04:08:07 2009 From: jamie at FreeBSD.org (Jamie Gritton) Date: Tue Sep 29 04:08:13 2009 Subject: Tutorial for Hierarchical Jails? In-Reply-To: References: <4AC0E5E6.1010700@FreeBSD.org> <20090928180731.M68375@maildrop.int.zabbadoz.net> <4AC12798.8070308@FreeBSD.org> Message-ID: <4AC18822.7020705@FreeBSD.org> Does the base system have security.jail.allow_raw_sockets=1? You need to have that, or set the jail's allow.raw_sockets. You can't set the jail's permissions from within the jail itself. If you have multiple jail levels, then both jails need to allow raw sockets - a jail can't allow a child jail to do what it can't do itself. - Jamie Edwin Shao wrote: > One other thing that is odd: hierarchical jails don't seem to inherit > some sysctls such as allow_raw_socket. > > In the host (jail), rc.conf has jail_set_allow_raw_sockets="YES" and > sysctl.conf has "security.jail.allow_raw_sockets=1", but no child jail > can ping out: > neko# ping google.com > ping: socket: Operation not permitted > > What is happening in this case? > > Thank you for your time again. > > > On Tue, Sep 29, 2009 at 12:16 AM, Jamie Gritton > wrote: > > The sysctls not only don't get written to, they don't have any useful > information to read either. They only describe the existence and format > of the various jail parameters. Sorry, but there;s no way to set a > default children.max parameter or inherit it from the parent. We've > decided to set the default to the most secure/restrictive in many cases. > Once we've come up with a new jail configuration interface, this won't > be such a hassle. > > The devfs errors are probably something that will have to be addressed > in a later revision - I haven't looked in the devfs direction so I'm not > sure about that. The mount error may be related to the first jail's > allow.mount parameter (whose default comes from > security.jail.mount_allowed). > > - Jamie > > Edwin Shao wrote: > > Thanks, that worked for me. > > * Using jail to change children.max on the parent does not > affect `sysctl security.jail.param.children.max` in the child. > Also security.jail.param.children.cur never changes either. Not > sure if that's intended behavior. > * Is there any way to persist the > security.jail.param.children.max parameter without entering the > jail command every time? * I get the following output when I > create a jail inside a jail: > > hyper ~> ezjail-admin start neko > Configuring jails:. > Starting jails:devfs rule: ioctl DEVFSIO_RGETNEXT: Operation not > permitted > devfs rule: ioctl DEVFSIO_RGETNEXT: Operation not permitted > /etc/rc.d/jail: WARNING: devfs_set_ruleset: you must specify a > ruleset number > devfs rule: ioctl DEVFSIO_SAPPLY: Operation not permitted > ln: log: Operation not permitted > mount: proc : Operation not permitted > neko. > > I'm using the same configuration values as in the parent's jail, > which work. Everything seems to work alright inside the jail, so > I assume the errors are safe to ignore? > > Thanks again! > - Edwin > > On Mon, Sep 28, 2009 at 9:11 PM, Bjoern A. Zeeb > > >> wrote: > > On Mon, 28 Sep 2009, Edwin Shao wrote: > > Hi Jamie, > When I try to change the parameter, nothing happens: > rescue /etc> sudo sysctl security.jail.param.children.max=1 > security.jail.param.children.max: 0 -> 0 > > rescue /etc> sudo sysctl security.jail.param.children.max > security.jail.param.children.max: 0 > > Am I doing this incorrectly? > > > Yes. It's a parameter to jail(8). The security.jail.param > sysctls can > be seen as a list of possible options valid to jail(8). See > man 8 jail > for the exact details. > > /bz > > -- Bjoern A. Zeeb What was I talking about and > who are you again? > > > From freebsd at optiksecurite.com Wed Sep 30 16:35:48 2009 From: freebsd at optiksecurite.com (Martin Turgeon) Date: Wed Sep 30 16:35:54 2009 Subject: Can't upgrade jails to 8.0 Message-ID: <4AC37ACC.4090201@optiksecurite.com> Hi everyone! I just upgraded a 7.2-REL to 8.0RC1 using freebsd-update. The upgrade went fine on the base system following the procedure written in the announcement email by Ken Smith. My problem is when I try to upgrade my jails, I get this message: # freebsd-update -b /usr/jail/mysql/ fetch install Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching metadata signature for 8.0-RC1 from update5.FreeBSD.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. No updates needed to update system to 8.0-RC1-p0. No updates are available to install. Run '/usr/sbin/freebsd-update fetch' first. But, if I compare the dates of the files in the base system to the files in the jails, it's obvious that the jails are not up to date. It seems like freebsd-update doesn't care about the basedir I specified. Thanks a lot for your help, Martin