From Alexander at Leidinger.net Sat Jul 4 06:35:37 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sat Jul 4 06:35:44 2009 Subject: Switching /etc/rc.d/jail to new syntax (+ new features) In-Reply-To: <4A48FA49.70600@FreeBSD.org> References: <20090627122519.00002b84@unknown> <20090627104704.Y22887@maildrop.int.zabbadoz.net> <20090627140803.00006830@unknown> <20090627121818.P22887@maildrop.int.zabbadoz.net> <20090627162424.00007289@unknown> <4A48FA49.70600@FreeBSD.org> Message-ID: <20090630100711.18745yont7x1lcjk@webmail.leidinger.net> Quoting Jamie Gritton (from Mon, 29 Jun 2009 11:30:49 -0600): > Alexander Leidinger wrote: > >>>>>> at http://www.leidinger.net/FreeBSD/current-patches/jail.diff I >>>>>> have a patch to switch the jail rc script to the new jail >>>>>> (8-current) syntax. This includes new config options for a jail >>>>>> (see etc/defaults/rc.conf after patching). The patch also contains >>>>>> my X-in-a-jail stuff (feel free to ignore this part, it's disabled >>>>>> by default). >>>>>> >>>>>> If you do not make any config change, you will be able to see all >>>>>> mounted filesystems of the entire machine. To get back to the >>>>>> previous behavior, you have to add a config option: >>>>>> jail_XXX_startparams="enforce_statfs=2" >>>>>> >>>>>> This config option can also take other jail parameters like >>>>>> allow.sysvipc and other ones described in the jail man-page >>>>>> (additional parameters need to be space separated). >>>>>> >>>>>> Feedback welcome. >>>>>> >>>>> 1) it break various things that will no longer work >>>>> >>>> As mentioned, it "breaks" the statfs part. If there's anything >>>> else, be more specific please. >>>> >>> v6, noIP, ... >>> >> >> I didn't change the IP handling in the rc script. Does this mean >> jail(8) works differently regarding the address parsing when called >> with the new parameters instead of the old options? >> >> I didn't test anything regarding ipv6, but as long as jail(8) doesn't >> behave differently with the new calling syntax compared with what we >> have in the tree, then the behavior is not differnt from what we have. >> If it behaves differently, this can be fixed in the script. >> > > There is a difference. Under the old options, IPv4 and IPv6 > addresses are mixed > into the single fixed argument, and then are parsed to determine > which kind they > are - both by jail(8) and rc.d/jail. Under the new parameter-based > command line, > IPv4 addresses and IPv6 address go with ip4.addr and ip6.addr respectively. But why are my jails (with only one ipv4 address) starting correctly then? > The rc.d/jail code that brings up addresses on an interface can be modified > to decide which argument the address goes with. > > I've given Bjoern a patch based on yours that handles this as well > as the allow.* > systctls (though I missed the statfs part). Do you mind making it available somewhere? Bye, Alexander. -- BOFH excuse #265: The mouse escaped http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From jamie at FreeBSD.org Sat Jul 4 16:12:56 2009 From: jamie at FreeBSD.org (Jamie Gritton) Date: Sat Jul 4 16:13:02 2009 Subject: Switching /etc/rc.d/jail to new syntax (+ new features) In-Reply-To: <20090630100711.18745yont7x1lcjk@webmail.leidinger.net> References: <20090627122519.00002b84@unknown> <20090627104704.Y22887@maildrop.int.zabbadoz.net> <20090627140803.00006830@unknown> <20090627121818.P22887@maildrop.int.zabbadoz.net> <20090627162424.00007289@unknown> <4A48FA49.70600@FreeBSD.org> <20090630100711.18745yont7x1lcjk@webmail.leidinger.net> Message-ID: <4A4F7F85.7030903@FreeBSD.org> Alexander Leidinger wrote: > Quoting Jamie Gritton (from Mon, 29 Jun 2009 > 11:30:49 -0600): > >> Alexander Leidinger wrote: >> >>>>>>> at http://www.leidinger.net/FreeBSD/current-patches/jail.diff I >>>>>>> have a patch to switch the jail rc script to the new jail >>>>>>> (8-current) syntax. This includes new config options for a jail >>>>>>> (see etc/defaults/rc.conf after patching). The patch also contains >>>>>>> my X-in-a-jail stuff (feel free to ignore this part, it's disabled >>>>>>> by default). >>>>>>> >>>>>>> If you do not make any config change, you will be able to see all >>>>>>> mounted filesystems of the entire machine. To get back to the >>>>>>> previous behavior, you have to add a config option: >>>>>>> jail_XXX_startparams="enforce_statfs=2" >>>>>>> >>>>>>> This config option can also take other jail parameters like >>>>>>> allow.sysvipc and other ones described in the jail man-page >>>>>>> (additional parameters need to be space separated). >>>>>>> >>>>>>> Feedback welcome. >>>>>>> >>>>>> 1) it break various things that will no longer work >>>>>> >>>>> As mentioned, it "breaks" the statfs part. If there's anything >>>>> else, be more specific please. >>>>> >>>> v6, noIP, ... >>>> >>> >>> I didn't change the IP handling in the rc script. Does this mean >>> jail(8) works differently regarding the address parsing when called >>> with the new parameters instead of the old options? >>> >>> I didn't test anything regarding ipv6, but as long as jail(8) doesn't >>> behave differently with the new calling syntax compared with what we >>> have in the tree, then the behavior is not differnt from what we have. >>> If it behaves differently, this can be fixed in the script. >>> >> >> There is a difference. Under the old options, IPv4 and IPv6 addresses >> are mixed >> into the single fixed argument, and then are parsed to determine which >> kind they >> are - both by jail(8) and rc.d/jail. Under the new parameter-based >> command line, >> IPv4 addresses and IPv6 address go with ip4.addr and ip6.addr >> respectively. > > But why are my jails (with only one ipv4 address) starting correctly then? The problem is that all addresses are put into ip4.addr, so it will break (only) if you have any IPv6 addresses. >> The rc.d/jail code that brings up addresses on an interface can be >> modified >> to decide which argument the address goes with. >> >> I've given Bjoern a patch based on yours that handles this as well as >> the allow.* >> systctls (though I missed the statfs part). > > Do you mind making it available somewhere? Sure. I've put it at http://gritton.org/freebsd/jail.rc.diff - Jamie From bugmaster at FreeBSD.org Mon Jul 6 11:07:01 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 6 11:08:40 2009 Subject: Current problem reports assigned to freebsd-jail@FreeBSD.org Message-ID: <200907061107.n66B70KB010823@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 bill.marquette at ucsecurity.com Tue Jul 7 01:29:47 2009 From: bill.marquette at ucsecurity.com (Bill Marquette) Date: Tue Jul 7 01:29:55 2009 Subject: Multicast in jail? Message-ID: <10880739.281246929242603.JavaMail.root@mail> I'm trying to run Avahi in a jail, much the same as Alexander Leidinger in this email from late last year http://www.mail-archive.com/freebsd-jail@freebsd.org/msg00587.html. I couldn't find any replies to that thread and it seems that I'm running into the same issues - the service announcements make it on the wire and the other devices in the network see them. However after some time, the other devices expire the service from their cache and ask for an update. As best as I can tell, the multicast update packets aren't making it into the jail (I can certainly imagine why not!). I don't have MROUTED compiled in the kernel, however the previously noted email did and it still didn't work. I'm running 8.0-CURRENT as of 27-June-2009 on this machine now, GENERIC kernel with WITNESS and INVARIANTS compiled out. Host: > ifmcstat em0: inet 192.168.69.100 igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 group 224.0.0.251 mode exclude mcast-macaddr 01:00:5e:00:00:fb group 224.0.0.1 mode exclude mcast-macaddr 01:00:5e:00:00:01 lo0: inet 127.0.0.1 igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 group 224.0.0.1 mode exclude inet6 fe80::1%lo0 mldv2 flags=0<> rv 2 qi 125 qri 10 uri 3 group ff01::1%lo0 mode exclude group ff02::2:736f:581e%lo0 mode exclude group ff02::1%lo0 mode exclude group ff02::1:ff00:1%lo0 mode exclude Jail: > ifmcstat lo0: inet6 fe80::1%lo0 mldv2 flags=0<> rv 2 qi 125 qri 10 uri 3 group ff01::1%lo0 mode exclude group ff02::2:736f:581e%lo0 mode exclude group ff02::1%lo0 mode exclude group ff02::1:ff00:1%lo0 mode exclude I'm pretty sure I saw em0 in the ifmcstat output for the jail the other day when I was messing with this, but I've rebooted since and have no idea what sequence of events led to that. I hope I'm just missing something and I can get this setup working. Any help would be most appreciated. Thanks --Bill From Alexander at Leidinger.net Tue Jul 7 09:21:00 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Tue Jul 7 09:21:06 2009 Subject: Multicast in jail? In-Reply-To: <10880739.281246929242603.JavaMail.root@mail> References: <10880739.281246929242603.JavaMail.root@mail> Message-ID: <20090707110149.93723i84ufre1vco@webmail.leidinger.net> Quoting Bill Marquette (from Mon, 6 Jul 2009 20:14:02 -0500 (CDT)): > I'm trying to run Avahi in a jail, much the same as Alexander > Leidinger in this email from late last year > http://www.mail-archive.com/freebsd-jail@freebsd.org/msg00587.html. > I couldn't find any replies to that thread and it seems that I'm > running into the same issues - the service announcements make it on > the wire and the other devices in the network see them. So far I have nothing working. I assume that the mcast traffic is not arriving at all IPs. Either because on overly restrictive jail check, and/or just because there's no code which is distributing the traffic to all IPs. It seems kern_jail.c is a place to check if there's some code which handles this. Maybe prison_check_ip[46] if mcast is on top of this, or something new to write if mcast is a different "AF". Again, this is a wild guess, I don't have enough understanding of the network code in the kernel to even make educated guesses about the real reason. Bye, Alexander. -- Ask not for whom the Bell tolls, and you will pay only the station-to-station rate. -- Howard Kandel http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From bzeeb-lists at lists.zabbadoz.net Tue Jul 7 11:10:08 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Tue Jul 7 11:11:47 2009 Subject: Multicast in jail? In-Reply-To: <20090707110149.93723i84ufre1vco@webmail.leidinger.net> References: <10880739.281246929242603.JavaMail.root@mail> <20090707110149.93723i84ufre1vco@webmail.leidinger.net> Message-ID: <20090707110601.U245@maildrop.int.zabbadoz.net> On Tue, 7 Jul 2009, Alexander Leidinger wrote: > Quoting Bill Marquette (from Mon, 6 Jul 2009 > 20:14:02 -0500 (CDT)): > >> I'm trying to run Avahi in a jail, much the same as Alexander Leidinger in >> this email from late last year >> http://www.mail-archive.com/freebsd-jail@freebsd.org/msg00587.html. I >> couldn't find any replies to that thread and it seems that I'm running into >> the same issues - the service announcements make it on the wire and the >> other devices in the network see them. > > So far I have nothing working. > > I assume that the mcast traffic is not arriving at all IPs. guess>Either because on overly restrictive jail check, and/or just because > there's no code which is distributing the traffic to all IPs. > > It seems kern_jail.c is a place to check if there's some code which handles No, in_pcb.c in6_pcb.c in_m*.[ch] in6_m*.[ch] are the files you need as a starting point; there's more and more and more. > this. Maybe prison_check_ip[46] if mcast is on top of this, or something new > to write if mcast is a different "AF". Again, this is a wild guess, I don't > have enough understanding of the network code in the kernel to even make > educated guesses about the real reason. But you first will have to understand all implications, that need a proper design plan and after that thoughtout implementation. Alternatively I wouldn't wonder if enabling raw sockets would give what you want or you'll wait for virtualization to be ready. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From Alexander at Leidinger.net Tue Jul 7 11:23:58 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Tue Jul 7 11:24:04 2009 Subject: Multicast in jail? In-Reply-To: <20090707110601.U245@maildrop.int.zabbadoz.net> References: <10880739.281246929242603.JavaMail.root@mail> <20090707110149.93723i84ufre1vco@webmail.leidinger.net> <20090707110601.U245@maildrop.int.zabbadoz.net> Message-ID: <20090707132347.17603crgm3ln9y4g@webmail.leidinger.net> Quoting "Bjoern A. Zeeb" (from Tue, 7 Jul 2009 11:08:46 +0000 (UTC)): > Alternatively I wouldn't wonder if enabling raw sockets would give Didn't work for me. > what you want or you'll wait for virtualization to be ready. As _I_ don't need it on -stable: it's what I'm waiting for. Bye, Alexander. -- The greatest of faults is to be conscious of none. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From bill.marquette at ucsecurity.com Tue Jul 7 13:47:34 2009 From: bill.marquette at ucsecurity.com (Bill Marquette) Date: Tue Jul 7 13:47:41 2009 Subject: Multicast in jail? In-Reply-To: <9276499.381246974079019.JavaMail.root@mail> Message-ID: <18147857.401246974433018.JavaMail.root@mail> ----- "Bjoern A. Zeeb" wrote: > On Tue, 7 Jul 2009, Alexander Leidinger wrote: > > > Quoting Bill Marquette (from Mon, 6 > Jul 2009 > > 20:14:02 -0500 (CDT)): > > > >> I'm trying to run Avahi in a jail, much the same as Alexander > Leidinger in > >> this email from late last year > >> http://www.mail-archive.com/freebsd-jail@freebsd.org/msg00587.html. > I > >> couldn't find any replies to that thread and it seems that I'm > running into > >> the same issues - the service announcements make it on the wire and > the > >> other devices in the network see them. > Alternatively I wouldn't wonder if enabling raw sockets would give > what you want or you'll wait for virtualization to be ready. I tried raw sockets also but as with Alexander, that didn't make any appreciable difference. In the short term I think I can work around this by bouncing Avahi every couple of minutes (it appears to work properly over the last couple minutes at least). I'm certainly willing to give VIMAGE a try if it's likely to fix the issue although by your statement, it sounds like it's unlikely to at this time. Thanks --Bill From scheidell at secnap.net Wed Jul 8 21:03:57 2009 From: scheidell at secnap.net (Michael Scheidell) Date: Wed Jul 8 21:04:03 2009 Subject: ssl accelerator cards and jail? Message-ID: <4A55055D.8030902@secnap.net> has anyone done any work with hardware ssl accelerator cards and freebsd? specifically, freebsd 7.1 amd64? and, is it transparent in 'jail' so all jailed servers can use the one card? -- Michael Scheidell, CTO Phone: 561-999-5000, x 1259 > *| *SECNAP Network Security Corporation * Certified SNORT Integrator * 2008-9 Hot Company Award Winner, World Executive Alliance * Five-Star Partner Program 2009, VARBusiness * Best Anti-Spam Product 2008, Network Products Guide * King of Spam Filters, SC Magazine 2008 _________________________________________________________________________ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.secnap.com/products/spammertrap/ _________________________________________________________________________ From bugmaster at FreeBSD.org Mon Jul 13 11:06:59 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 13 11:08:46 2009 Subject: Current problem reports assigned to freebsd-jail@FreeBSD.org Message-ID: <200907131106.n6DB6vtF040657@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 linimon at FreeBSD.org Sun Jul 19 20:41:18 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Jul 19 20:41:29 2009 Subject: kern/136899: [jail] [lor] upd/jail LOR after reboot Message-ID: <200907192041.n6JKfHY0091779@freefall.freebsd.org> Old Synopsis: upd/jail LOR after reboot New Synopsis: [jail] [lor] upd/jail LOR after reboot Responsible-Changed-From-To: freebsd-bugs->freebsd-jail Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jul 19 20:40:50 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=136899 From bugmaster at FreeBSD.org Mon Jul 20 11:06:58 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 20 11:08:43 2009 Subject: Current problem reports assigned to freebsd-jail@FreeBSD.org Message-ID: <200907201106.n6KB6vQ5002331@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/136899 jail [jail] [lor] upd/jail LOR after reboot 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 5 problems total. From jamie at FreeBSD.org Tue Jul 21 21:44:31 2009 From: jamie at FreeBSD.org (Jamie Gritton) Date: Tue Jul 21 21:44:37 2009 Subject: Jail parameter patch: disable/new/inherit Message-ID: <4A6636B8.9050204@FreeBSD.org> There's a patch to Current at http://gritton.org/freebsd/triple.diff that makes some small changes to the new parameter based jail system. I invite any interested in the future direction of jails to review it before it goes in (hopefully in the next day or two). This patch deals with jailed subsystems that may or may not be virtualized. At first, there was a boolean to describe this situation: for example in the VIMAGE kernels, the setting "vnet" parameter would create a jail with a virtual network stack. But there's more than just virtual or not. In particular there are three things that can be done with a particular subsystem: "disable": Don't use the subsystem at all in a jail. For example, if you create a jail with "ip6=disable", that jail won't be able to use IPv6 sockets, as if it were a system without INET6 defined in the kernel. "new": Create a new virtual instance of the subsystem in the jail. What constitutes a new instance will vary, but it generally means the jail is treated in some way different from the rest of the system. Setting "ip6=new" will restrict IPv6 addresses (to the contents of the list specified by "ip6.addr" which should also be set). Setting "host=new" will let a jail set its own hostname (and related data) separately from the rest of the system. Setting "vnet=new" will create a new network stack for the jail. "inherit": This is the default state, and means the jail is treated the same as the rest of the system. There's no difference between a jailed and non-jailed process as far as that subsystem is concerned. A jail with "ip6=inherit" would allow the full use of the available IPv6 addresses. As yet, this is just a structural/name change. It will become important as other features are added to the jail system, including any modules that want to have jail support. - Jamie From scheidell at secnap.net Fri Jul 24 16:11:13 2009 From: scheidell at secnap.net (Michael Scheidell) Date: Fri Jul 24 16:11:20 2009 Subject: ssl accelerator cards and jail? In-Reply-To: <1248451401.24024.1262.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> References: <4A55055D.8030902@secnap.net> <1248451401.24024.1262.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> Message-ID: <4A69DD4A.60406@secnap.net> Brian A. Seklecki wrote: > On Wed, 2009-07-08 at 16:45 -0400, Michael Scheidell wrote: > >> has anyone done any work with hardware ssl accelerator cards and freebsd? >> >> > > I'm pretty sure. Because it is a;; one kernel, the userland->kernel > sysctls just fall through to the host. > > I've been meaning to try the VMWare ESXi 4.0 PCI card passthrough > feature. > > Let me pass my Sun Crypto 1000 (BCM5921/23) through to a Jailhost > FreeBSD 7.2, then try it within a jail. Should be quite a head trip. > > thanks. maybe I'll look into one of those and give it a try on 7.1 (worries me that 7.2 has a shorted lifespan than 7.1...) -- Michael Scheidell, CTO Phone: 561-999-5000, x 1259 > *| *SECNAP Network Security Corporation * Certified SNORT Integrator * 2008-9 Hot Company Award Winner, World Executive Alliance * Five-Star Partner Program 2009, VARBusiness * Best Anti-Spam Product 2008, Network Products Guide * King of Spam Filters, SC Magazine 2008 _________________________________________________________________________ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.secnap.com/products/spammertrap/ _________________________________________________________________________ From seklecki at noc.cfi.pgh.pa.us Fri Jul 24 16:18:28 2009 From: seklecki at noc.cfi.pgh.pa.us (Brian A. Seklecki) Date: Fri Jul 24 16:18:35 2009 Subject: ssl accelerator cards and jail? In-Reply-To: <4A55055D.8030902@secnap.net> References: <4A55055D.8030902@secnap.net> Message-ID: <1248451401.24024.1262.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> On Wed, 2009-07-08 at 16:45 -0400, Michael Scheidell wrote: > has anyone done any work with hardware ssl accelerator cards and freebsd? > I'm pretty sure. Because it is a;; one kernel, the userland->kernel sysctls just fall through to the host. I've been meaning to try the VMWare ESXi 4.0 PCI card passthrough feature. Let me pass my Sun Crypto 1000 (BCM5921/23) through to a Jailhost FreeBSD 7.2, then try it within a jail. Should be quite a head trip. ~BAS > specifically, freebsd 7.1 amd64? > > and, is it transparent in 'jail' so all jailed servers can use the one card? > > From seklecki at noc.cfi.pgh.pa.us Fri Jul 24 20:25:49 2009 From: seklecki at noc.cfi.pgh.pa.us (Brian A. Seklecki) Date: Fri Jul 24 20:25:56 2009 Subject: ssl accelerator cards and jail? In-Reply-To: <4A69DD4A.60406@secnap.net> References: <4A55055D.8030902@secnap.net> <1248451401.24024.1262.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <4A69DD4A.60406@secnap.net> Message-ID: <1248467146.24024.2056.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> On Fri, 2009-07-24 at 12:11 -0400, Michael Scheidell wrote: > thanks. maybe I'll look into one of those and give it a try on 7.1 > (worries me that 7.2 has a shorted lifespan than 7.1...) That's by design per the releng document. Hey, my ESXi 4.0 machine is PCI-Express only. My Broadcom cards are 32bit PCI-X. I had a PCI-E but had to return it as a demo. Give me a few days to hack some testing together. ~BAS From bugmaster at FreeBSD.org Mon Jul 27 11:06:57 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 27 11:08:49 2009 Subject: Current problem reports assigned to freebsd-jail@FreeBSD.org Message-ID: <200907271106.n6RB6umC018991@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/136899 jail [jail] [lor] upd/jail LOR after reboot 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 5 problems total. From bz at FreeBSD.org Mon Jul 27 14:53:26 2009 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Mon Jul 27 14:53:32 2009 Subject: 8.0 still allow creating ipv6 udp socket in jail without ipv6 ip In-Reply-To: <20090725163207.GP39538@expo.ukrweb.net> References: <20090725163207.GP39538@expo.ukrweb.net> Message-ID: <20090727141808.R245@maildrop.int.zabbadoz.net> On Sat, 25 Jul 2009, Mykola Dzham wrote: Hi, > After r188146 creating tcp ipv6 socket in jail without ipv6 ip is not > allowed, but udp socket is allowed. I cannot really follow what you are trying to say as wrt IPv4 and IPv6 sockets and what about UDP. Your sample further down is trying to use an IPv4 address on an IPv6 Datagram socket which is an error either way. Prior to FreeBSD 7.2 IPv6 hadn't been supported at all for jails. With 7.2 it was possible to create IPv6 sockets (but only shortly and then fail on bind/connect/...). With the commit you reference the "Protocol not supported" came back in case there was no address of that address family for a given jail. With 8 the primary syntax for jails has changed and the "backward compat mode" again allows you to create a socket on a jail even if no address of the same family was configured for the jail. This should be addressed by the following patch: http://people.freebsd.org/~bz/20090727-01-jail8-legacy.diff Can you give it a try and report if that fixes your problem? Regards, Bjoern -- Bjoern A. Zeeb The greatest risk is not taking one. From artis.caune at gmail.com Tue Jul 28 14:36:23 2009 From: artis.caune at gmail.com (Artis Caune) Date: Tue Jul 28 14:36:29 2009 Subject: Jails on ZFS Message-ID: <9e20d71e0907280716m3968f42pe7aeed2b0286302c@mail.gmail.com> Hi, I'm playing with jails on ZFS and everything is fine, except annoying warnings (hopefully just warnings) when doing: # /etc/rc.d/jail stop zfs_umount:971[0]: Force unmount is experimental - report any problems. ... zfs_umount:971[0]: Force unmount is experimental - report any problems. I found that in rc.d/jail secure_umount() it always do "umount -f " Maybe it's better first try to unmount without -f and then use force? --- /etc/rc.d/jail 2009-07-22 23:29:29.000000000 +0300 +++ /etc/rc.d/jail 2009-07-28 14:00:19.998368729 +0300 @@ -270,7 +270,7 @@ _dir=$1 if is_current_mountpoint ${_dir}; then - umount -f ${_dir} >/dev/null 2>&1 + umount ${_dir} >/dev/null 2>&1 || { sleep 2; umount ${_dir} >/dev/null 2>&1 || umount -f ${_dir} >/dev/null 2>&1; } else debug "Nothing mounted on ${_dir} - not unmounting" fi -- Artis Caune Everything should be made as simple as possible, but not simpler. From askjuise at gmail.com Tue Jul 28 15:19:52 2009 From: askjuise at gmail.com (Alexander Petrovsky) Date: Tue Jul 28 15:20:24 2009 Subject: Jails on ZFS In-Reply-To: <9e20d71e0907280716m3968f42pe7aeed2b0286302c@mail.gmail.com> References: <9e20d71e0907280716m3968f42pe7aeed2b0286302c@mail.gmail.com> Message-ID: <2ec071a80907280748p336f6356p78d2debcfd8cd18b@mail.gmail.com> > > Hi, > > I'm playing with jails on ZFS and everything is fine, except annoying > warnings (hopefully just warnings) when doing: > # /etc/rc.d/jail stop > > zfs_umount:971[0]: Force unmount is experimental - report any problems. > ... > zfs_umount:971[0]: Force unmount is experimental - report any problems. > > > I found that in rc.d/jail secure_umount() it always do "umount -f " > > Maybe it's better first try to unmount without -f and then use force? > > > --- /etc/rc.d/jail 2009-07-22 23:29:29.000000000 +0300 > +++ /etc/rc.d/jail 2009-07-28 14:00:19.998368729 +0300 > @@ -270,7 +270,7 @@ > _dir=$1 > > if is_current_mountpoint ${_dir}; then > - umount -f ${_dir} >/dev/null 2>&1 > + umount ${_dir} >/dev/null 2>&1 || { sleep 2; umount ${_dir} > >/dev/null 2>&1 || umount -f ${_dir} >/dev/null 2>&1; } > else > debug "Nothing mounted on ${_dir} - not unmounting" > fi > Hi, it is may be good idea. But, I can't understand your code, why you do - umount ${_dir} >/dev/null 2>&1 || { sleep 2; umount ${_dir} >/dev/null 2>&1 || umount -f ${_dir} >/dev/null 2>&1; } instead umount ${_dir} >/dev/null 2>&1 || umount -f ${_dir} >/dev/null 2>&1 ? -- ? ????????? ?????????? ?????????, With the best regards Alexander Petrovsky, ICQ: 350342118 Jabber: juise@jabber.ru Phone: +7 914 8 820 815 From artis.caune at gmail.com Tue Jul 28 18:34:50 2009 From: artis.caune at gmail.com (Artis Caune) Date: Tue Jul 28 18:34:57 2009 Subject: Jails on ZFS In-Reply-To: <2ec071a80907280748p336f6356p78d2debcfd8cd18b@mail.gmail.com> References: <9e20d71e0907280716m3968f42pe7aeed2b0286302c@mail.gmail.com> <2ec071a80907280748p336f6356p78d2debcfd8cd18b@mail.gmail.com> Message-ID: <9e20d71e0907281134j41f767ddrf3dc2e3154d724a4@mail.gmail.com> 2009/7/28 Alexander Petrovsky : > Hi, it is may be good idea. But, I can't understand your code, why you do - > ?umount ${_dir} >/dev/null 2>&1 || { sleep 2; umount ${_dir} >/dev/null 2>&1 > || umount -f ${_dir} >/dev/null 2>&1; } > > instead > ?umount ${_dir} >/dev/null 2>&1 || umount -f ${_dir} >/dev/null 2>&1 > > ? Because when jail is shuting down, file system is still busy. I think this is because of syslogd, which has no rc.d shutdown keyword, and so it's been killed. Immediately after killing all jail processes, file systems are unmounted. It helps sleeping 1, 2 seconds and then trying to unmount it, and if fs is still busy, force unmount it. Maybe this is better: --- /etc/rc.d/jail 2009-07-22 23:29:29.000000000 +0300 +++ /etc/rc.d/jail 2009-07-28 21:23:30.436217867 +0300 @@ -270,7 +270,7 @@ _dir=$1 if is_current_mountpoint ${_dir}; then - umount -f ${_dir} >/dev/null 2>&1 + umount ${_dir} >/dev/null 2>&1 || umount -f ${_dir} >/dev/null 2>&1 else debug "Nothing mounted on ${_dir} - not unmounting" fi @@ -700,6 +700,7 @@ killall -j ${_jail_id} -TERM > /dev/null 2>&1 sleep 1 killall -j ${_jail_id} -KILL > /dev/null 2>&1 + sleep 2 jail_umount_fs echo -n " $_hostname" -- Artis Caune Everything should be made as simple as possible, but not simpler. From freebsd at levsha.org.ua Wed Jul 29 11:56:31 2009 From: freebsd at levsha.org.ua (Mykola Dzham) Date: Wed Jul 29 11:56:38 2009 Subject: 8.0 still allow creating ipv6 udp socket in jail without ipv6 ip In-Reply-To: <20090727141808.R245@maildrop.int.zabbadoz.net> References: <20090725163207.GP39538@expo.ukrweb.net> <20090727141808.R245@maildrop.int.zabbadoz.net> Message-ID: <20090729113638.GC20855@expo.ukrweb.net> Bjoern A. Zeeb wrote: > On Sat, 25 Jul 2009, Mykola Dzham wrote: > > Hi, > > > After r188146 creating tcp ipv6 socket in jail without ipv6 ip is not > > allowed, but udp socket is allowed. > > I cannot really follow what you are trying to say as wrt IPv4 and IPv6 > sockets and what about UDP. > > Your sample further down is trying to use an IPv4 address on an IPv6 > Datagram socket which is an error either way. Some java programms attempt to use ipv6 sockets, then use ipv4 if socket(AF_INET6,...) fail. My sample imitate this > Prior to FreeBSD 7.2 IPv6 hadn't been supported at all for jails. > > With 7.2 it was possible to create IPv6 sockets (but only shortly and > then fail on bind/connect/...). With the commit you reference the > "Protocol not supported" came back in case there was no address of > that address family for a given jail. > > With 8 the primary syntax for jails has changed and the "backward > compat mode" again allows you to create a socket on a jail even if > no address of the same family was configured for the jail. > > This should be addressed by the following patch: > http://people.freebsd.org/~bz/20090727-01-jail8-legacy.diff > > Can you give it a try and report if that fixes your problem? Patch aplied cleanly on r195820 , but jail can not start after patching: # jail -l -U root -i /usr/home/d/guests/tap2 tap2.my.domain.com 10.112.0.151 /bin/sh /etc/rc jail: ip6: unknown boolean value "disable" -- LEFT-(UANIC|RIPE) JID: levsha@jabber.net.ua PGP fingerprint: 2A0B 7423 51AF B19B 74D5 31CA 2BFF 42F1 8094 7652 From bz at FreeBSD.org Wed Jul 29 12:20:09 2009 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Wed Jul 29 12:20:24 2009 Subject: 8.0 still allow creating ipv6 udp socket in jail without ipv6 ip In-Reply-To: <20090729113638.GC20855@expo.ukrweb.net> References: <20090725163207.GP39538@expo.ukrweb.net> <20090727141808.R245@maildrop.int.zabbadoz.net> <20090729113638.GC20855@expo.ukrweb.net> Message-ID: <20090729121834.B245@maildrop.int.zabbadoz.net> On Wed, 29 Jul 2009, Mykola Dzham wrote: Hi, > Bjoern A. Zeeb wrote: >> On Sat, 25 Jul 2009, Mykola Dzham wrote: >> >> Hi, >> >>> After r188146 creating tcp ipv6 socket in jail without ipv6 ip is not >>> allowed, but udp socket is allowed. >> >> I cannot really follow what you are trying to say as wrt IPv4 and IPv6 >> sockets and what about UDP. >> >> Your sample further down is trying to use an IPv4 address on an IPv6 >> Datagram socket which is an error either way. > > Some java programms attempt to use ipv6 sockets, then use ipv4 if > socket(AF_INET6,...) fail. My sample imitate this > >> Prior to FreeBSD 7.2 IPv6 hadn't been supported at all for jails. >> >> With 7.2 it was possible to create IPv6 sockets (but only shortly and >> then fail on bind/connect/...). With the commit you reference the >> "Protocol not supported" came back in case there was no address of >> that address family for a given jail. >> >> With 8 the primary syntax for jails has changed and the "backward >> compat mode" again allows you to create a socket on a jail even if >> no address of the same family was configured for the jail. >> >> This should be addressed by the following patch: >> http://people.freebsd.org/~bz/20090727-01-jail8-legacy.diff >> >> Can you give it a try and report if that fixes your problem? > > Patch aplied cleanly on r195820 , but jail can not start after patching: > > # jail -l -U root -i /usr/home/d/guests/tap2 tap2.my.domain.com 10.112.0.151 /bin/sh /etc/rc > jail: ip6: unknown boolean value "disable" r195820 is too old; but Jamie has a better solution; I would suggest to backout the jail(8) patch and wait for the next two commits of Jamie to HEAD and then update the machine again. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From jamie at FreeBSD.org Wed Jul 29 17:48:07 2009 From: jamie at FreeBSD.org (Jamie Gritton) Date: Wed Jul 29 17:48:14 2009 Subject: 8.0 still allow creating ipv6 udp socket in jail without ipv6 ip In-Reply-To: <20090729121834.B245@maildrop.int.zabbadoz.net> References: <20090725163207.GP39538@expo.ukrweb.net> <20090727141808.R245@maildrop.int.zabbadoz.net> <20090729113638.GC20855@expo.ukrweb.net> <20090729121834.B245@maildrop.int.zabbadoz.net> Message-ID: <4A708261.7000509@FreeBSD.org> Bjoern A. Zeeb wrote: > On Wed, 29 Jul 2009, Mykola Dzham wrote: >> Bjoern A. Zeeb wrote: >>> On Sat, 25 Jul 2009, Mykola Dzham wrote: >>>> After r188146 creating tcp ipv6 socket in jail without ipv6 ip is not >>>> allowed, but udp socket is allowed. >>> >>> I cannot really follow what you are trying to say as wrt IPv4 and IPv6 >>> sockets and what about UDP. >>> >>> Your sample further down is trying to use an IPv4 address on an IPv6 >>> Datagram socket which is an error either way. >> >> Some java programms attempt to use ipv6 sockets, then use ipv4 if >> socket(AF_INET6,...) fail. My sample imitate this >> >>> Prior to FreeBSD 7.2 IPv6 hadn't been supported at all for jails. >>> >>> With 7.2 it was possible to create IPv6 sockets (but only shortly and >>> then fail on bind/connect/...). With the commit you reference the >>> "Protocol not supported" came back in case there was no address of >>> that address family for a given jail. >>> >>> With 8 the primary syntax for jails has changed and the "backward >>> compat mode" again allows you to create a socket on a jail even if >>> no address of the same family was configured for the jail. >>> >>> This should be addressed by the following patch: >>> http://people.freebsd.org/~bz/20090727-01-jail8-legacy.diff >>> >>> Can you give it a try and report if that fixes your problem? >> >> Patch aplied cleanly on r195820 , but jail can not start after patching: >> >> # jail -l -U root -i /usr/home/d/guests/tap2 tap2.my.domain.com >> 10.112.0.151 /bin/sh /etc/rc >> jail: ip6: unknown boolean value "disable" > > r195820 is too old; but Jamie has a better solution; I would suggest > to backout the jail(8) patch and wait for the next two commits of > Jamie to HEAD and then update the machine again. OK, with r195945 things should be back to disallowing sockets when no addresses were assigned for that family. You'll need to rebuild the kernel for the fix, and libjail and possibly jail(8) to get past the "unknown boolean value" error. - Jamie From freebsd at levsha.org.ua Thu Jul 30 13:50:44 2009 From: freebsd at levsha.org.ua (Mykola Dzham) Date: Thu Jul 30 13:50:51 2009 Subject: 8.0 still allow creating ipv6 udp socket in jail without ipv6 ip In-Reply-To: <4A708261.7000509@FreeBSD.org> References: <20090725163207.GP39538@expo.ukrweb.net> <20090727141808.R245@maildrop.int.zabbadoz.net> <20090729113638.GC20855@expo.ukrweb.net> <20090729121834.B245@maildrop.int.zabbadoz.net> <4A708261.7000509@FreeBSD.org> Message-ID: <20090730135139.GF20855@expo.ukrweb.net> Jamie Gritton wrote: > Bjoern A. Zeeb wrote: > > On Wed, 29 Jul 2009, Mykola Dzham wrote: > >> Bjoern A. Zeeb wrote: > >>> On Sat, 25 Jul 2009, Mykola Dzham wrote: > >>>> After r188146 creating tcp ipv6 socket in jail without ipv6 ip is not > >>>> allowed, but udp socket is allowed. > >>> > >>> I cannot really follow what you are trying to say as wrt IPv4 and IPv6 > >>> sockets and what about UDP. > >>> > >>> Your sample further down is trying to use an IPv4 address on an IPv6 > >>> Datagram socket which is an error either way. > >> > >> Some java programms attempt to use ipv6 sockets, then use ipv4 if > >> socket(AF_INET6,...) fail. My sample imitate this > >> > >>> Prior to FreeBSD 7.2 IPv6 hadn't been supported at all for jails. > >>> > >>> With 7.2 it was possible to create IPv6 sockets (but only shortly and > >>> then fail on bind/connect/...). With the commit you reference the > >>> "Protocol not supported" came back in case there was no address of > >>> that address family for a given jail. > >>> > >>> With 8 the primary syntax for jails has changed and the "backward > >>> compat mode" again allows you to create a socket on a jail even if > >>> no address of the same family was configured for the jail. > >>> > >>> This should be addressed by the following patch: > >>> http://people.freebsd.org/~bz/20090727-01-jail8-legacy.diff > >>> > >>> Can you give it a try and report if that fixes your problem? > >> > >> Patch aplied cleanly on r195820 , but jail can not start after patching: > >> > >> # jail -l -U root -i /usr/home/d/guests/tap2 tap2.my.domain.com > >> 10.112.0.151 /bin/sh /etc/rc > >> jail: ip6: unknown boolean value "disable" > > > > r195820 is too old; but Jamie has a better solution; I would suggest > > to backout the jail(8) patch and wait for the next two commits of > > Jamie to HEAD and then update the machine again. > > OK, with r195945 things should be back to disallowing sockets when no > addresses were assigned for that family. You'll need to rebuild the > kernel for the fix, and libjail and possibly jail(8) to get past the > "unknown boolean value" error. On r195949 test program work correctly: it fail on socket(AF_INET6,...) on jail without ipv6 address. Thanks! -- Mykola Dzham, LEFT-(UANIC|RIPE) JID: levsha@jabber.net.ua From dfilter at FreeBSD.ORG Thu Jul 30 14:30:08 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Thu Jul 30 14:30:18 2009 Subject: kern/136899: commit references a PR Message-ID: <200907301430.n6UEU81X009974@freefall.freebsd.org> The following reply was made to PR kern/136899; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/136899: commit references a PR Date: Thu, 30 Jul 2009 14:29:07 +0000 (UTC) Author: jamie Date: Thu Jul 30 14:28:56 2009 New Revision: 195974 URL: http://svn.freebsd.org/changeset/base/195974 Log: Remove a LOR, where the the sleepable allprison_lock was being obtained in prison_equal_ip4/6 while an inp mutex was held. Locking allprison_lock can be avoided by making a restriction on the IP addresses associated with jails: Don't allow the "ip4" and "ip6" parameters to be changed after a jail is created. Setting the "ip4.addr" and "ip6.addr" parameters is allowed, but only if the jail was already created with either ip4/6=new or ip4/6=disable. With this restriction, the prison flags in question (PR_IP4_USER and PR_IP6_USER) become read-only and can be checked without locking. This also allows the simplification of a messy code path that was needed to handle an existing prison gaining an IP address list. PR: kern/136899 Reported by: Dirk Meyer Approved by: re (kib), bz (mentor) Modified: head/sys/kern/kern_jail.c Modified: head/sys/kern/kern_jail.c ============================================================================== --- head/sys/kern/kern_jail.c Thu Jul 30 13:19:12 2009 (r195973) +++ head/sys/kern/kern_jail.c Thu Jul 30 14:28:56 2009 (r195974) @@ -484,10 +484,10 @@ kern_jail_set(struct thread *td, struct int ii, ij; #endif #ifdef INET - int ip4s, ip4a, redo_ip4; + int ip4s, redo_ip4; #endif #ifdef INET6 - int ip6s, ip6a, redo_ip6; + int ip6s, redo_ip6; #endif unsigned pr_flags, ch_flags; unsigned pr_allow, ch_allow, tallow; @@ -518,17 +518,12 @@ kern_jail_set(struct thread *td, struct if (error) return (error); #ifdef INET - ip4a = 0; ip4 = NULL; #endif #ifdef INET6 - ip6a = 0; ip6 = NULL; #endif -#if defined(INET) || defined(INET6) - again: -#endif error = vfs_copyopt(opts, "jid", &jid, sizeof(jid)); if (error == ENOENT) jid = 0; @@ -610,6 +605,20 @@ kern_jail_set(struct thread *td, struct goto done_errmsg; } #endif +#ifdef INET + if ((flags & JAIL_UPDATE) && (ch_flags & PR_IP4_USER)) { + error = EINVAL; + vfs_opterror(opts, "ip4 cannot be changed after creation"); + goto done_errmsg; + } +#endif +#ifdef INET6 + if ((flags & JAIL_UPDATE) && (ch_flags & PR_IP6_USER)) { + error = EINVAL; + vfs_opterror(opts, "ip6 cannot be changed after creation"); + goto done_errmsg; + } +#endif pr_allow = ch_allow = 0; for (fi = 0; fi < sizeof(pr_allow_names) / sizeof(pr_allow_names[0]); @@ -708,7 +717,6 @@ kern_jail_set(struct thread *td, struct pr_flags |= PR_HOST; } - /* This might be the second time around for this option. */ #ifdef INET error = vfs_getopt(opts, "ip4.addr", &op, &ip4s); if (error == ENOENT) @@ -730,14 +738,7 @@ kern_jail_set(struct thread *td, struct vfs_opterror(opts, "too many IPv4 addresses"); goto done_errmsg; } - if (ip4a < ip4s) { - ip4a = ip4s; - free(ip4, M_PRISON); - ip4 = NULL; - } - if (ip4 == NULL) - ip4 = malloc(ip4a * sizeof(*ip4), M_PRISON, - M_WAITOK); + ip4 = malloc(ip4s * sizeof(*ip4), M_PRISON, M_WAITOK); bcopy(op, ip4, ip4s * sizeof(*ip4)); /* * IP addresses are all sorted but ip[0] to preserve @@ -793,14 +794,7 @@ kern_jail_set(struct thread *td, struct vfs_opterror(opts, "too many IPv6 addresses"); goto done_errmsg; } - if (ip6a < ip6s) { - ip6a = ip6s; - free(ip6, M_PRISON); - ip6 = NULL; - } - if (ip6 == NULL) - ip6 = malloc(ip6a * sizeof(*ip6), M_PRISON, - M_WAITOK); + ip6 = malloc(ip6s * sizeof(*ip6), M_PRISON, M_WAITOK); bcopy(op, ip6, ip6s * sizeof(*ip6)); if (ip6s > 1) qsort(ip6 + 1, ip6s - 1, sizeof(*ip6), qcmp_v6); @@ -1152,10 +1146,36 @@ kern_jail_set(struct thread *td, struct #endif { #ifdef INET - pr->pr_flags |= PR_IP4 | PR_IP4_USER | PR_IP4_DISABLE; + if (!(ch_flags & PR_IP4_USER)) + pr->pr_flags |= + PR_IP4 | PR_IP4_USER | PR_IP4_DISABLE; + else if (!(pr_flags & PR_IP4_USER)) { + pr->pr_flags |= ppr->pr_flags & PR_IP4; + if (ppr->pr_ip4 != NULL) { + pr->pr_ip4s = ppr->pr_ip4s; + pr->pr_ip4 = malloc(pr->pr_ip4s * + sizeof(struct in_addr), M_PRISON, + M_WAITOK); + bcopy(ppr->pr_ip4, pr->pr_ip4, + pr->pr_ip4s * sizeof(*pr->pr_ip4)); + } + } #endif #ifdef INET6 - pr->pr_flags |= PR_IP6 | PR_IP6_USER | PR_IP6_DISABLE; + if (!(ch_flags & PR_IP6_USER)) + pr->pr_flags |= + PR_IP6 | PR_IP6_USER | PR_IP6_DISABLE; + else if (!(pr_flags & PR_IP6_USER)) { + pr->pr_flags |= ppr->pr_flags & PR_IP6; + if (ppr->pr_ip6 != NULL) { + pr->pr_ip6s = ppr->pr_ip6s; + pr->pr_ip6 = malloc(pr->pr_ip6s * + sizeof(struct in6_addr), M_PRISON, + M_WAITOK); + bcopy(ppr->pr_ip6, pr->pr_ip6, + pr->pr_ip6s * sizeof(*pr->pr_ip6)); + } + } #endif } #endif @@ -1189,6 +1209,11 @@ kern_jail_set(struct thread *td, struct */ } else { created = 0; + /* + * Grab a reference for existing prisons, to ensure they + * continue to exist for the duration of the call. + */ + pr->pr_ref++; #if defined(VIMAGE) && (defined(INET) || defined(INET6)) if ((pr->pr_flags & PR_VNET) && (ch_flags & (PR_IP4_USER | PR_IP6_USER))) { @@ -1198,11 +1223,22 @@ kern_jail_set(struct thread *td, struct goto done_deref_locked; } #endif - /* - * Grab a reference for existing prisons, to ensure they - * continue to exist for the duration of the call. - */ - pr->pr_ref++; +#ifdef INET + if (PR_IP4_USER & ch_flags & (pr_flags ^ pr->pr_flags)) { + error = EINVAL; + vfs_opterror(opts, + "ip4 cannot be changed after creation"); + goto done_deref_locked; + } +#endif +#ifdef INET6 + if (PR_IP6_USER & ch_flags & (pr_flags ^ pr->pr_flags)) { + error = EINVAL; + vfs_opterror(opts, + "ip6 cannot be changed after creation"); + goto done_deref_locked; + } +#endif } /* Do final error checking before setting anything. */ @@ -1225,254 +1261,138 @@ kern_jail_set(struct thread *td, struct } } #ifdef INET - if (ch_flags & PR_IP4_USER) { + if (ip4s > 0) { if (ppr->pr_flags & PR_IP4) { - if (!(pr_flags & PR_IP4_USER)) { - /* - * Silently ignore attempts to make the IP - * addresses unrestricted when the parent is - * restricted; in other words, interpret - * "unrestricted" as "as unrestricted as - * possible". - */ - ip4s = ppr->pr_ip4s; - if (ip4s == 0) { - free(ip4, M_PRISON); - ip4 = NULL; - } else if (ip4s <= ip4a) { - /* Inherit the parent's address(es). */ - bcopy(ppr->pr_ip4, ip4, - ip4s * sizeof(*ip4)); - } else { - /* - * There's no room for the parent's - * address list. Allocate some more. - */ - ip4a = ip4s; - free(ip4, M_PRISON); - ip4 = malloc(ip4a * sizeof(*ip4), - M_PRISON, M_NOWAIT); - if (ip4 != NULL) - bcopy(ppr->pr_ip4, ip4, - ip4s * sizeof(*ip4)); - else { - /* Allocation failed without - * sleeping. Unlocking the - * prison now will invalidate - * some checks and prematurely - * show an unfinished new jail. - * So let go of everything and - * start over. - */ - prison_deref(pr, created - ? PD_LOCKED | - PD_LIST_XLOCKED - : PD_DEREF | PD_LOCKED | - PD_LIST_XLOCKED); - if (root != NULL) { - vfslocked = - VFS_LOCK_GIANT( - root->v_mount); - vrele(root); - VFS_UNLOCK_GIANT( - vfslocked); - } - ip4 = malloc(ip4a * - sizeof(*ip4), M_PRISON, - M_WAITOK); - goto again; - } - } - } else if (ip4s > 0) { - /* - * Make sure the new set of IP addresses is a - * subset of the parent's list. Don't worry - * about the parent being unlocked, as any - * setting is done with allprison_lock held. - */ - for (ij = 0; ij < ppr->pr_ip4s; ij++) - if (ip4[0].s_addr == - ppr->pr_ip4[ij].s_addr) + /* + * Make sure the new set of IP addresses is a + * subset of the parent's list. Don't worry + * about the parent being unlocked, as any + * setting is done with allprison_lock held. + */ + for (ij = 0; ij < ppr->pr_ip4s; ij++) + if (ip4[0].s_addr == ppr->pr_ip4[ij].s_addr) + break; + if (ij == ppr->pr_ip4s) { + error = EPERM; + goto done_deref_locked; + } + if (ip4s > 1) { + for (ii = ij = 1; ii < ip4s; ii++) { + if (ip4[ii].s_addr == + ppr->pr_ip4[0].s_addr) + continue; + for (; ij < ppr->pr_ip4s; ij++) + if (ip4[ii].s_addr == + ppr->pr_ip4[ij].s_addr) + break; + if (ij == ppr->pr_ip4s) break; + } if (ij == ppr->pr_ip4s) { error = EPERM; goto done_deref_locked; } - if (ip4s > 1) { - for (ii = ij = 1; ii < ip4s; ii++) { - if (ip4[ii].s_addr == - ppr->pr_ip4[0].s_addr) - continue; - for (; ij < ppr->pr_ip4s; ij++) - if (ip4[ii].s_addr == - ppr->pr_ip4[ij].s_addr) - break; - if (ij == ppr->pr_ip4s) - break; - } - if (ij == ppr->pr_ip4s) { - error = EPERM; - goto done_deref_locked; - } - } } } - if (ip4s > 0) { - /* - * Check for conflicting IP addresses. We permit them - * if there is no more than one IP on each jail. If - * there is a duplicate on a jail with more than one - * IP stop checking and return error. - */ - tppr = ppr; + /* + * Check for conflicting IP addresses. We permit them + * if there is no more than one IP on each jail. If + * there is a duplicate on a jail with more than one + * IP stop checking and return error. + */ + tppr = ppr; #ifdef VIMAGE - for (; tppr != &prison0; tppr = tppr->pr_parent) - if (tppr->pr_flags & PR_VNET) - break; + for (; tppr != &prison0; tppr = tppr->pr_parent) + if (tppr->pr_flags & PR_VNET) + break; #endif - FOREACH_PRISON_DESCENDANT(tppr, tpr, descend) { - if (tpr == pr || + FOREACH_PRISON_DESCENDANT(tppr, tpr, descend) { + if (tpr == pr || #ifdef VIMAGE - (tpr != tppr && - (tpr->pr_flags & PR_VNET)) || + (tpr != tppr && (tpr->pr_flags & PR_VNET)) || #endif - tpr->pr_uref == 0) { - descend = 0; - continue; - } - if (!(tpr->pr_flags & PR_IP4_USER)) - continue; + tpr->pr_uref == 0) { descend = 0; - if (tpr->pr_ip4 == NULL || - (ip4s == 1 && tpr->pr_ip4s == 1)) - continue; - for (ii = 0; ii < ip4s; ii++) { - if (_prison_check_ip4(tpr, - &ip4[ii]) == 0) { - error = EADDRINUSE; - vfs_opterror(opts, - "IPv4 addresses clash"); - goto done_deref_locked; - } + continue; + } + if (!(tpr->pr_flags & PR_IP4_USER)) + continue; + descend = 0; + if (tpr->pr_ip4 == NULL || + (ip4s == 1 && tpr->pr_ip4s == 1)) + continue; + for (ii = 0; ii < ip4s; ii++) { + if (_prison_check_ip4(tpr, &ip4[ii]) == 0) { + error = EADDRINUSE; + vfs_opterror(opts, + "IPv4 addresses clash"); + goto done_deref_locked; } } } } #endif #ifdef INET6 - if (ch_flags & PR_IP6_USER) { + if (ip6s > 0) { if (ppr->pr_flags & PR_IP6) { - if (!(pr_flags & PR_IP6_USER)) { - /* - * Silently ignore attempts to make the IP - * addresses unrestricted when the parent is - * restricted. - */ - ip6s = ppr->pr_ip6s; - if (ip6s == 0) { - free(ip6, M_PRISON); - ip6 = NULL; - } else if (ip6s <= ip6a) { - /* Inherit the parent's address(es). */ - bcopy(ppr->pr_ip6, ip6, - ip6s * sizeof(*ip6)); - } else { - /* - * There's no room for the parent's - * address list. - */ - ip6a = ip6s; - free(ip6, M_PRISON); - ip6 = malloc(ip6a * sizeof(*ip6), - M_PRISON, M_NOWAIT); - if (ip6 != NULL) - bcopy(ppr->pr_ip6, ip6, - ip6s * sizeof(*ip6)); - else { - prison_deref(pr, created - ? PD_LOCKED | - PD_LIST_XLOCKED - : PD_DEREF | PD_LOCKED | - PD_LIST_XLOCKED); - if (root != NULL) { - vfslocked = - VFS_LOCK_GIANT( - root->v_mount); - vrele(root); - VFS_UNLOCK_GIANT( - vfslocked); - } - ip6 = malloc(ip6a * - sizeof(*ip6), M_PRISON, - M_WAITOK); - goto again; - } - } - } else if (ip6s > 0) { - /* - * Make sure the new set of IP addresses is a - * subset of the parent's list. - */ - for (ij = 0; ij < ppr->pr_ip6s; ij++) - if (IN6_ARE_ADDR_EQUAL(&ip6[0], - &ppr->pr_ip6[ij])) + /* + * Make sure the new set of IP addresses is a + * subset of the parent's list. + */ + for (ij = 0; ij < ppr->pr_ip6s; ij++) + if (IN6_ARE_ADDR_EQUAL(&ip6[0], + &ppr->pr_ip6[ij])) + break; + if (ij == ppr->pr_ip6s) { + error = EPERM; + goto done_deref_locked; + } + if (ip6s > 1) { + for (ii = ij = 1; ii < ip6s; ii++) { + if (IN6_ARE_ADDR_EQUAL(&ip6[ii], + &ppr->pr_ip6[0])) + continue; + for (; ij < ppr->pr_ip6s; ij++) + if (IN6_ARE_ADDR_EQUAL( + &ip6[ii], &ppr->pr_ip6[ij])) + break; + if (ij == ppr->pr_ip6s) break; + } if (ij == ppr->pr_ip6s) { error = EPERM; goto done_deref_locked; } - if (ip6s > 1) { - for (ii = ij = 1; ii < ip6s; ii++) { - if (IN6_ARE_ADDR_EQUAL(&ip6[ii], - &ppr->pr_ip6[0])) - continue; - for (; ij < ppr->pr_ip6s; ij++) - if (IN6_ARE_ADDR_EQUAL( - &ip6[ii], - &ppr->pr_ip6[ij])) - break; - if (ij == ppr->pr_ip6s) - break; - } - if (ij == ppr->pr_ip6s) { - error = EPERM; - goto done_deref_locked; - } - } } } - if (ip6s > 0) { - /* Check for conflicting IP addresses. */ - tppr = ppr; + /* Check for conflicting IP addresses. */ + tppr = ppr; #ifdef VIMAGE - for (; tppr != &prison0; tppr = tppr->pr_parent) - if (tppr->pr_flags & PR_VNET) - break; + for (; tppr != &prison0; tppr = tppr->pr_parent) + if (tppr->pr_flags & PR_VNET) + break; #endif - FOREACH_PRISON_DESCENDANT(tppr, tpr, descend) { - if (tpr == pr || + FOREACH_PRISON_DESCENDANT(tppr, tpr, descend) { + if (tpr == pr || #ifdef VIMAGE - (tpr != tppr && - (tpr->pr_flags & PR_VNET)) || + (tpr != tppr && (tpr->pr_flags & PR_VNET)) || #endif - tpr->pr_uref == 0) { - descend = 0; - continue; - } - if (!(tpr->pr_flags & PR_IP6_USER)) - continue; + tpr->pr_uref == 0) { descend = 0; - if (tpr->pr_ip6 == NULL || - (ip6s == 1 && tpr->pr_ip6s == 1)) - continue; - for (ii = 0; ii < ip6s; ii++) { - if (_prison_check_ip6(tpr, - &ip6[ii]) == 0) { - error = EADDRINUSE; - vfs_opterror(opts, - "IPv6 addresses clash"); - goto done_deref_locked; - } + continue; + } + if (!(tpr->pr_flags & PR_IP6_USER)) + continue; + descend = 0; + if (tpr->pr_ip6 == NULL || + (ip6s == 1 && tpr->pr_ip6s == 1)) + continue; + for (ii = 0; ii < ip6s; ii++) { + if (_prison_check_ip6(tpr, &ip6[ii]) == 0) { + error = EADDRINUSE; + vfs_opterror(opts, + "IPv6 addresses clash"); + goto done_deref_locked; } } } @@ -1514,28 +1434,12 @@ kern_jail_set(struct thread *td, struct /* Set the parameters of the prison. */ #ifdef INET redo_ip4 = 0; - if (ch_flags & PR_IP4_USER) { - if (pr_flags & PR_IP4_USER) { - /* Some restriction set. */ - pr->pr_flags |= PR_IP4; - if (ip4s >= 0) { - free(pr->pr_ip4, M_PRISON); - pr->pr_ip4s = ip4s; - pr->pr_ip4 = ip4; - ip4 = NULL; - } - } else if (ppr->pr_flags & PR_IP4) { - /* This restriction cleared, but keep inherited. */ - free(pr->pr_ip4, M_PRISON); - pr->pr_ip4s = ip4s; - pr->pr_ip4 = ip4; - ip4 = NULL; - } else { - /* Restriction cleared, now unrestricted. */ - pr->pr_flags &= ~PR_IP4; - free(pr->pr_ip4, M_PRISON); - pr->pr_ip4s = 0; - } + if (pr_flags & PR_IP4_USER) { + pr->pr_flags |= PR_IP4; + free(pr->pr_ip4, M_PRISON); + pr->pr_ip4s = ip4s; + pr->pr_ip4 = ip4; + ip4 = NULL; FOREACH_PRISON_DESCENDANT_LOCKED(pr, tpr, descend) { #ifdef VIMAGE if (tpr->pr_flags & PR_VNET) { @@ -1552,28 +1456,12 @@ kern_jail_set(struct thread *td, struct #endif #ifdef INET6 redo_ip6 = 0; - if (ch_flags & PR_IP6_USER) { - if (pr_flags & PR_IP6_USER) { - /* Some restriction set. */ - pr->pr_flags |= PR_IP6; - if (ip6s >= 0) { - free(pr->pr_ip6, M_PRISON); - pr->pr_ip6s = ip6s; - pr->pr_ip6 = ip6; - ip6 = NULL; - } - } else if (ppr->pr_flags & PR_IP6) { - /* This restriction cleared, but keep inherited. */ - free(pr->pr_ip6, M_PRISON); - pr->pr_ip6s = ip6s; - pr->pr_ip6 = ip6; - ip6 = NULL; - } else { - /* Restriction cleared, now unrestricted. */ - pr->pr_flags &= ~PR_IP6; - free(pr->pr_ip6, M_PRISON); - pr->pr_ip6s = 0; - } + if (pr_flags & PR_IP6_USER) { + pr->pr_flags |= PR_IP6; + free(pr->pr_ip6, M_PRISON); + pr->pr_ip6s = ip6s; + pr->pr_ip6 = ip6; + ip6 = NULL; FOREACH_PRISON_DESCENDANT_LOCKED(pr, tpr, descend) { #ifdef VIMAGE if (tpr->pr_flags & PR_VNET) { @@ -2661,7 +2549,6 @@ prison_restrict_ip4(struct prison *pr, s free(pr->pr_ip4, M_PRISON); pr->pr_ip4 = newip4; pr->pr_ip4s = ppr->pr_ip4s; - pr->pr_flags |= PR_IP4; } return (used); } @@ -2673,9 +2560,7 @@ prison_restrict_ip4(struct prison *pr, s free(pr->pr_ip4, M_PRISON); pr->pr_ip4 = NULL; } - pr->pr_flags = - (pr->pr_flags & ~PR_IP4) | (ppr->pr_flags & PR_IP4); - } else if (pr->pr_ip4s > 0 && (ppr->pr_flags & PR_IP4)) { + } else if (pr->pr_ip4s > 0) { /* Remove addresses that aren't in the parent. */ for (ij = 0; ij < ppr->pr_ip4s; ij++) if (pr->pr_ip4[0].s_addr == ppr->pr_ip4[ij].s_addr) @@ -2762,12 +2647,9 @@ prison_equal_ip4(struct prison *pr1, str return (1); /* - * jail_set maintains an exclusive hold on allprison_lock while it - * changes the IP addresses, so only a shared hold is needed. This is - * easier than locking the two prisons which would require finding the - * proper locking order and end up needing allprison_lock anyway. + * No need to lock since the PR_IP4_USER flag can't be altered for + * existing prisons. */ - sx_slock(&allprison_lock); while (pr1 != &prison0 && #ifdef VIMAGE !(pr1->pr_flags & PR_VNET) && @@ -2780,7 +2662,6 @@ prison_equal_ip4(struct prison *pr1, str #endif !(pr2->pr_flags & PR_IP4_USER)) pr2 = pr2->pr_parent; - sx_sunlock(&allprison_lock); return (pr1 == pr2); } @@ -2972,7 +2853,6 @@ prison_restrict_ip6(struct prison *pr, s free(pr->pr_ip6, M_PRISON); pr->pr_ip6 = newip6; pr->pr_ip6s = ppr->pr_ip6s; - pr->pr_flags |= PR_IP6; } return (used); } @@ -2984,9 +2864,7 @@ prison_restrict_ip6(struct prison *pr, s free(pr->pr_ip6, M_PRISON); pr->pr_ip6 = NULL; } - pr->pr_flags = - (pr->pr_flags & ~PR_IP6) | (ppr->pr_flags & PR_IP6); - } else if (pr->pr_ip6s > 0 && (ppr->pr_flags & PR_IP6)) { + } else if (pr->pr_ip6s > 0) { /* Remove addresses that aren't in the parent. */ for (ij = 0; ij < ppr->pr_ip6s; ij++) if (IN6_ARE_ADDR_EQUAL(&pr->pr_ip6[0], @@ -3073,7 +2951,6 @@ prison_equal_ip6(struct prison *pr1, str if (pr1 == pr2) return (1); - sx_slock(&allprison_lock); while (pr1 != &prison0 && #ifdef VIMAGE !(pr1->pr_flags & PR_VNET) && @@ -3086,7 +2963,6 @@ prison_equal_ip6(struct prison *pr1, str #endif !(pr2->pr_flags & PR_IP6_USER)) pr2 = pr2->pr_parent; - sx_sunlock(&allprison_lock); return (pr1 == pr2); } @@ -4172,12 +4048,14 @@ SYSCTL_JAIL_PARAM_NODE(cpuset, "Jail cpu SYSCTL_JAIL_PARAM(_cpuset, id, CTLTYPE_INT | CTLFLAG_RD, "I", "Jail cpuset ID"); #ifdef INET -SYSCTL_JAIL_PARAM_SYS_NODE(ip4, CTLFLAG_RW, "Jail IPv4 address virtualization"); +SYSCTL_JAIL_PARAM_SYS_NODE(ip4, CTLFLAG_RDTUN, + "Jail IPv4 address virtualization"); SYSCTL_JAIL_PARAM_STRUCT(_ip4, addr, CTLFLAG_RW, sizeof(struct in_addr), "S,in_addr,a", "Jail IPv4 addresses"); #endif #ifdef INET6 -SYSCTL_JAIL_PARAM_SYS_NODE(ip6, CTLFLAG_RW, "Jail IPv6 address virtualization"); +SYSCTL_JAIL_PARAM_SYS_NODE(ip6, CTLFLAG_RDTUN, + "Jail IPv6 address virtualization"); SYSCTL_JAIL_PARAM_STRUCT(_ip6, addr, CTLFLAG_RW, sizeof(struct in6_addr), "S,in6_addr,a", "Jail IPv6 addresses"); #endif _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From jamie at FreeBSD.org Thu Jul 30 15:54:37 2009 From: jamie at FreeBSD.org (jamie@FreeBSD.org) Date: Thu Jul 30 15:54:43 2009 Subject: kern/136899: [jail] [lor] upd/jail LOR after reboot Message-ID: <200907301554.n6UFsZMf079883@freefall.freebsd.org> Synopsis: [jail] [lor] upd/jail LOR after reboot State-Changed-From-To: open->closed State-Changed-By: jamie State-Changed-When: Thu Jul 30 15:42:26 UTC 2009 State-Changed-Why: Fixed by r195974, which restricts the prison "ip4" and "ip6" parameters in order to avoid locking allprison_lock in prison_equal_ip4/6. http://www.freebsd.org/cgi/query-pr.cgi?pr=136899 From nvass9573 at gmx.com Fri Jul 31 07:46:31 2009 From: nvass9573 at gmx.com (Nikos Vassiliadis) Date: Fri Jul 31 07:46:39 2009 Subject: creating vimage with jail(8)? Message-ID: <4A72A133.2030801@gmx.com> Hi, Is it possible to create a vimage with the jail(8) command? Or one have still to use the tools/tools/vimage command? Thanks, Nikos From nvass9573 at gmx.com Fri Jul 31 07:57:08 2009 From: nvass9573 at gmx.com (Nikos Vassiliadis) Date: Fri Jul 31 07:57:14 2009 Subject: creating vimage with jail(8)? In-Reply-To: <4A72A133.2030801@gmx.com> References: <4A72A133.2030801@gmx.com> Message-ID: <4A72A3BD.1030208@gmx.com> Nikos Vassiliadis wrote: > Is it possible to create a vimage with the jail(8) command? > Or one have still to use the tools/tools/vimage command? Sorry for the noise, I've just saw a two weeks old post from Jamie Gritton, mentioning that the vnet parameter should be used: > This patch deals with jailed subsystems that may or may not be > virtualized. At first, there was a boolean to describe this > situation: for example in the VIMAGE kernels, the setting "vnet" > parameter would create a jail with a virtual network stack.