From lists.freebsd at gmail.com Mon Jun 1 01:56:43 2009 From: lists.freebsd at gmail.com (Richard Noorlandt) Date: Mon Jun 1 01:56:50 2009 Subject: Implications of allow_raw_sockets=1 In-Reply-To: <5da021490905311447ya99c484ucaeabc74e813f394@mail.gmail.com> References: <99c92b5f0905311149u4023d197s7302fae0b816d463@mail.gmail.com> <5da021490905311447ya99c484ucaeabc74e813f394@mail.gmail.com> Message-ID: <99c92b5f0905311856r4cb9e23apfd36b806b0250f45@mail.gmail.com> 2009/5/31 Justin G. : > Raw sockets can allow processes to sniff onto the network, craft > malformed packets, execute DDoS attacks, inject packets, among other > things. These are basically things that any non-virtualized server could do on the network. As such, disallowing raw sockets should give higher security than a 'normal' server running FreeBSD without a jail. But does the use of raw sockets open up holes that could allow the root user in a jail to break in on another jail? I'm particularly concerned in attack vectors that wouldn't exist with multiple real hosts connected through a dumb switch (which usually introduces all the risks you mentioned). Best regards, Richard From bugmaster at FreeBSD.org Mon Jun 1 11:06:59 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 1 11:08:37 2009 Subject: Current problem reports assigned to freebsd-jail@FreeBSD.org Message-ID: <200906011106.n51B6s7e021126@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/134583 jail [jail] [hang] Machine with jail freezes after random a o kern/133265 jail [jail] is there a solution how to run nfs client in ja o kern/132092 jail [jail] jail can listen on *:port when jail_socket_unix 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 6 problems total. From scrappy at hub.org Wed Jun 3 21:20:05 2009 From: scrappy at hub.org (Marc G. Fournier) Date: Wed Jun 3 21:20:14 2009 Subject: Calculating per jail memory usage ... Message-ID: <20090603180221.E56412@hub.org> Are there any tools for this that are either in ports, or others would like to share? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 From lists at c0mplx.org Wed Jun 3 23:03:09 2009 From: lists at c0mplx.org (Kurt Jaeger) Date: Wed Jun 3 23:03:15 2009 Subject: Calculating per jail memory usage ... In-Reply-To: <20090603180221.E56412@hub.org> References: <20090603180221.E56412@hub.org> Message-ID: <20090603230306.GF10978@home.opsec.eu> Hi! > Are there any tools for this that are either in ports, or others would > like to share? This perl snippet works pretty good: # return memory/proc usage per jail and system sub vmem { my(@res); my($i); my($ip); my(@t); @res = `/bin/ps ax -o 'pid,jid,rss,vsz,args' 2>&1`; shift(@res); foreach $i (@res) { $i = " ".$i; @t=split(/ +/,$i); # print "i: $i t1: $t[2]\n"; $jproc{$t[2]}++; $jrealm{$t[2]} += $t[3]; $jvirtm{$t[2]} += $t[4]; } foreach $i (keys(%running)) { $ip=$vs2ip{$i}; if ( defined($jproc{$ip2jid{$ip}}) ) { $runproc{$i} = $jproc{$ip2jid{$ip}} - 1 } else { $runproc{$i} = 0; } $runrealm{$i} = $jrealm{$ip2jid{$ip}}; $runvirtm{$i} = $jvirtm{$ip2jid{$ip}}; } } -- pi@opsec.eu +49 171 3101372 11 years to go ! From kostjn at peterhost.ru Thu Jun 4 05:35:07 2009 From: kostjn at peterhost.ru (Menshikov Konstantin) Date: Thu Jun 4 05:35:15 2009 Subject: Calculating per jail memory usage ... In-Reply-To: <20090603180221.E56412@hub.org> References: <20090603180221.E56412@hub.org> Message-ID: <4A275D80.5050408@peterhost.ru> Marc G. Fournier wrote: > > Are there any tools for this that are either in ports, or others would > like to share? > > ---- > Marc G. Fournier Hub.Org Networking Services > (http://www.hub.org) > Email . scrappy@hub.org MSN . > scrappy@hub.org > Yahoo . yscrappy Skype: hub.org ICQ . 7615664 > _______________________________________________ > 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" > Hi. You can consider memory occupied with processes in jail as sum RSS of these processes, but it is wrong. Processes divide memory among themselves, a segment of the text or all memory (if not to do exec after fork). Now in a kernel there is no mechanism with which help it is possible to count a memory size occupied with processes in jail. After this mechanism will appear, it will be possible to add top :) There is a patch for restriction of resources jail, http://wiki.freebsd.org/Jails, CPU + RAM Limits for Current. In it, it is considered memory which is used by processes in jail. Further using a system call jail_get it is possible to receive a memory size used jail. The program jget thus works. Example [root@book /home/kostjn]# ./jget.o 1 Jail limits and rusage, jid = 1 Limits: CPU 5, MEM 64M, NPROC 128, NOFILE 512 Usage: CPU 0, MEM 6M, NPROC 9, NOFILE 65 -- Menshikov Konstantin From andrew at modulus.org Thu Jun 4 05:54:27 2009 From: andrew at modulus.org (Andrew Snow) Date: Thu Jun 4 05:54:43 2009 Subject: Calculating per jail memory usage ... In-Reply-To: <4A275D80.5050408@peterhost.ru> References: <20090603180221.E56412@hub.org> <4A275D80.5050408@peterhost.ru> Message-ID: <4A275CE4.9020408@modulus.org> Menshikov Konstantin wrote: > Now in a kernel there is no mechanism with which help it is possible to > count a memory size occupied with processes in jail. > After this mechanism will appear, it will be possible to add top :) Are there any plans to add this? There needs to be a way more generally (ie. not just for jails) to find out total memory used by a set of processes which may or may not have shared memory. - Andrew From kostjn at peterhost.ru Thu Jun 4 05:59:53 2009 From: kostjn at peterhost.ru (Menshikov Konstantin) Date: Thu Jun 4 06:00:00 2009 Subject: Calculating per jail memory usage ... In-Reply-To: <4A275CE4.9020408@modulus.org> References: <20090603180221.E56412@hub.org> <4A275D80.5050408@peterhost.ru> <4A275CE4.9020408@modulus.org> Message-ID: <4A276356.7040704@peterhost.ru> Andrew Snow wrote: > Menshikov Konstantin wrote: >> Now in a kernel there is no mechanism with which help it is possible >> to count a memory size occupied with processes in jail. >> After this mechanism will appear, it will be possible to add top :) > > Are there any plans to add this? > > There needs to be a way more generally (ie. not just for jails) to > find out total memory used by a set of processes which may or may not > have shared memory. > > > - Andrew > > The patch will be added, after testing, I hope. In a case jail it was necessary for memory size restriction. I do not think that in a kernel it is necessary to add possibility of definition of the size of memory occupied with any group of processes. Easier to count memory as conclusion parsing pmap (/usr/ports/sysutils/pmap/) output for several processes. From bsam at ipt.ru Thu Jun 4 14:08:59 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Thu Jun 4 14:09:05 2009 Subject: sysvipc in jails + CURRENT In-Reply-To: <20090603130503.202126d6v3glhhq8@mail.lidstrom.eu> ("Henrik =?utf-8?Q?Lidstr=C3=B6m=22's?= message of "Wed\, 03 Jun 2009 13\:05\:03 +0200") References: <11979393@h30.sp.ipt.ru> <20090531174837.R3234@maildrop.int.zabbadoz.net> <20090603130503.202126d6v3glhhq8@mail.lidstrom.eu> Message-ID: <36883384@bb.ipt.ru> On Wed, 03 Jun 2009 13:05:03 +0200 Henrik Lidstr?m wrote: > Quoting "Bjoern A. Zeeb" : > > On Sun, 31 May 2009, Boris Samorodov wrote: > > > > Hi, > > > >> has something changed at CURRENT with sysvipc jail handling? > >> This jail has been working fine for almost a year. > >> > >> I've upgrade CURRENT to yesterday's sources and can't start > >> postgresql in a jail anymore: > >> ----- the jail ----- > >> % tail -2 /var/log/messages > >> May 31 18:22:47 pg postgres[55425]: [1-1] FATAL: could not create > >> shared memory segment: Function not implemented > >> May 31 18:22:47 pg postgres[55425]: [1-2] DETAIL: Failed system > >> call was shmget(key=5432001, size=30384128, 03600). > >> % sysctl security.jail.sysvipc_allowed > >> security.jail.sysvipc_allowed: 0 > >> % grep sysvipc /etc/sysctl.conf > >> security.jail.sysvipc_allowed=1 > >> ----- the host ----- > >> % uname -a > >> FreeBSD tba.bsam.ru 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun May 31 > >> 11:28:31 MSD 2009 root@tba.bsam.ru:/usr/obj/usr/src/sys/TBA > >> amd64 > >> % sysctl security.jail.sysvipc_allowed > >> security.jail.sysvipc_allowed: 1 > >> ----- > > > > I'll look into that; possibly the default option is not properly taken > > into account for the new jail framework. > > > > /bz > > > > -- > > Bjoern A. Zeeb The greatest risk is not taking one. > > _______________________________________________ > > 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" > > > Somehow I cant email to the mailinglist(it doesnt show up), so I send > directly to you. > I also noticed the problem with security.jail.sysvipc_allowed as above. > Also noticed that I from a jail now can see all filesystems (and that > jls -v is broken, probably a problem with cpuset?). > EXTBSD02-PROD# uname -a > FreeBSD EXTBSD02-PROD.digidoc.com 8.0-CURRENT FreeBSD 8.0-CURRENT #6: > Tue Jun 2 10:05:40 CEST 2009 > root@EXTBSD02-PROD.digidoc.com:/data01/obj/usr/src/sys/EXTBSD02 i386 > EXTBSD02-PROD# jls -v > jls: unknown parameter: cpuset > EXTBSD02-PROD# > EXTBSD02-PROD# jls > JID IP Address Hostname Path > 1 195.67.11.41 INTDB01-PROD > /data00/jails/INTDB01-PROD > 2 195.67.11.9 INTLOG01-PROD.digidoc.com > /data00/jails/INTLOG01-PROD > 3 62.20.119.164 EXTNS01-PROD > /data00/jails/EXTNS01-PROD > 4 62.20.119.230 PROXY03.digidoc.com /data00/jails/PROXY03 > EXTBSD02-PROD# jexec 1 /bin/csh > You have mail. > INTDB01-PROD# mount -v > /dev/da0s1a on / (ufs, local) > devfs on /dev (devfs, local) > /dev/da0s1e on /tmp (ufs, local, soft-updates) > /dev/da0s1f on /usr (ufs, local, noatime, soft-updates) > /dev/da0s1d on /var (ufs, local, noatime, soft-updates) > /dev/da0s2a on /data00 (ufs, local, noatime, soft-updates) > /dev/da1s1d on /data01 (ufs, local, noatime, soft-updates) > tmpfs on /data00/jails/PROXY03/usr/local/squid/scan_dir (tmpfs, local) > /data01/data/ports on /data00/jails/EXTNS01-PROD/usr/ports (nullfs, > local, noatime) > /data01/data/ports on /data00/jails/INTDB01-PROD/usr/ports (nullfs, > local, noatime) > /data01/data/ports on /data00/jails/INTLOG01-PROD/usr/ports (nullfs, > local, noatime) > /data01/data/ports on /data00/jails/INTSIM01-PROD/usr/ports (nullfs, > local, noatime) > /data01/data/ports on /data00/jails/PROXY03/usr/ports (nullfs, local, noatime) > /data01/backup/INTDB01PROD/databases on > /data00/jails/INTDB01-PROD/usr/backup (nullfs, local, noatime) > devfs on /data00/jails/INTDB01-PROD/dev (devfs, local) > procfs on /data00/jails/INTDB01-PROD/proc (procfs, local) > devfs on /data00/jails/INTLOG01-PROD/dev (devfs, local) > procfs on /data00/jails/INTLOG01-PROD/proc (procfs, local) > devfs on /data00/jails/EXTNS01-PROD/dev (devfs, local) > procfs on /data00/jails/EXTNS01-PROD/proc (procfs, local) > devfs on /data00/jails/PROXY03/dev (devfs, local) > procfs on /data00/jails/PROXY03/proc (procfs, local) > INTDB01-PROD# There is definitely some inconsistency. JAIL(8) at recent CURRENT talk about security.jail.param.allow.sysvipc and it is listed via "sysctl -d security.jail.param". But seems not to be used: ----- at the jail ----- # sysctl security.jail.param.allow.sysvipc # ----- WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From bzeeb-lists at lists.zabbadoz.net Thu Jun 4 20:55:07 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Thu Jun 4 20:55:14 2009 Subject: sysvipc in jails + CURRENT In-Reply-To: <36883384@bb.ipt.ru> References: <11979393@h30.sp.ipt.ru> <20090531174837.R3234@maildrop.int.zabbadoz.net> <20090603130503.202126d6v3glhhq8@mail.lidstrom.eu> <36883384@bb.ipt.ru> Message-ID: <20090604204751.Y12292@maildrop.int.zabbadoz.net> On Thu, 4 Jun 2009, Boris Samorodov wrote: Hi, > There is definitely some inconsistency. JAIL(8) at recent > CURRENT talk about security.jail.param.allow.sysvipc and > it is listed via "sysctl -d security.jail.param". But seems > not to be used: > ----- at the jail ----- > # sysctl security.jail.param.allow.sysvipc > # > ----- If you can use an old jail binary things should work for you for the moment. The jail(8) compat code that still supports the old syntax but already uses the new syscall does not take the old sysctls into account - the problem you are seeing. Alternatively you could try updating the jail by hand using the new syntax and switch sysvipc on. The bug will probably be fixed latest somewhen next week and I just got back and have a huge backlog and Jamie will be back in a few days I think. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From scrappy at hub.org Fri Jun 5 09:02:24 2009 From: scrappy at hub.org (Marc G. Fournier) Date: Fri Jun 5 09:02:31 2009 Subject: Calculating per jail memory usage ... In-Reply-To: <4A275D80.5050408@peterhost.ru> References: <20090603180221.E56412@hub.org> <4A275D80.5050408@peterhost.ru> Message-ID: <20090605055852.N56412@hub.org> On Thu, 4 Jun 2009, Menshikov Konstantin wrote: > Hi. > You can consider memory occupied with processes in jail as sum RSS of these > processes, but it is wrong. > > Processes divide memory among themselves, a segment of the text or all memory > (if not to do exec after fork). > > Now in a kernel there is no mechanism with which help it is possible to count > a memory size occupied with processes in jail. > After this mechanism will appear, it will be possible to add top :) > > There is a patch for restriction of resources jail, > http://wiki.freebsd.org/Jails, CPU + RAM Limits for Current. Is this the ChrisJones patch that is labeled "Not fully working / stalled" you are referring to? For 7.x, all we can really go back is RSS, from what I can tell ... it won't be until 8.x(?) that we will be able to get more accurate ... ? And even then, it will be a patch we have to add, not stuff that has been yet integrated into 8.x? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 From kostjn at peterhost.ru Fri Jun 5 09:32:01 2009 From: kostjn at peterhost.ru (Menshikov Konstantin) Date: Fri Jun 5 09:32:09 2009 Subject: Calculating per jail memory usage ... In-Reply-To: <20090605055852.N56412@hub.org> References: <20090603180221.E56412@hub.org> <4A275D80.5050408@peterhost.ru> <20090605055852.N56412@hub.org> Message-ID: <4A28E691.9010301@peterhost.ru> Marc G. Fournier wrote: > On Thu, 4 Jun 2009, Menshikov Konstantin wrote: > >> Hi. >> You can consider memory occupied with processes in jail as sum RSS of >> these processes, but it is wrong. >> >> Processes divide memory among themselves, a segment of the text or >> all memory (if not to do exec after fork). >> >> Now in a kernel there is no mechanism with which help it is possible >> to count a memory size occupied with processes in jail. >> After this mechanism will appear, it will be possible to add top :) >> >> There is a patch for restriction of resources jail, >> http://wiki.freebsd.org/Jails, CPU + RAM Limits for Current. > > Is this the ChrisJones patch that is labeled "Not fully working / > stalled" you are referring to? No, it is a patch written with zero. > > For 7.x, all we can really go back is RSS, from what I can tell ... it > won't be until 8.x(?) that we will be able to get more accurate ... ? > And even then, it will be a patch we have to add, not stuff that has > been yet integrated into 8.x? Yes, the kernel has no counters of memory for jail in 7 branch, also has no system calls jail_get, jail_set, therefore on there is no place to take the information. In 8 branch are added jail_set, jail_get, it gives the chance to obtain any data about jail. I hope that after a while, after testing, the patch for restriction of use of resources jail will be accepted. After that, reception of the information on use of resources jail will be trivial. From 000.fbsd at quip.cz Fri Jun 5 09:35:29 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Fri Jun 5 09:35:39 2009 Subject: Calculating per jail memory usage ... In-Reply-To: <20090605055852.N56412@hub.org> References: <20090603180221.E56412@hub.org> <4A275D80.5050408@peterhost.ru> <20090605055852.N56412@hub.org> Message-ID: <4A28E305.8080608@quip.cz> Marc G. Fournier wrote: > On Thu, 4 Jun 2009, Menshikov Konstantin wrote: > >> Hi. >> You can consider memory occupied with processes in jail as sum RSS of >> these processes, but it is wrong. >> >> Processes divide memory among themselves, a segment of the text or all >> memory (if not to do exec after fork). >> >> Now in a kernel there is no mechanism with which help it is possible >> to count a memory size occupied with processes in jail. >> After this mechanism will appear, it will be possible to add top :) >> >> There is a patch for restriction of resources jail, >> http://wiki.freebsd.org/Jails, CPU + RAM Limits for Current. > > > Is this the ChrisJones patch that is labeled "Not fully working / > stalled" you are referring to? Yes and no. Patches in the last column of this table is from different authors. Chris Jones is no longer working on this. The latest patch is from Menshikov Konstantin :) see http://kostjn.spb.ru/patch-jail-limit-8CURRENT.README Miroslav Lachman From bugmaster at FreeBSD.org Mon Jun 8 11:06:56 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 8 11:08:44 2009 Subject: Current problem reports assigned to freebsd-jail@FreeBSD.org Message-ID: <200906081106.n58B6thT020693@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/134583 jail [jail] [hang] Machine with jail freezes after random a o kern/133265 jail [jail] is there a solution how to run nfs client in ja o kern/132092 jail [jail] jail can listen on *:port when jail_socket_unix 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 6 problems total. From bz at FreeBSD.org Mon Jun 8 17:14:21 2009 From: bz at FreeBSD.org (bz@FreeBSD.org) Date: Mon Jun 8 17:14:28 2009 Subject: kern/134583: [hang] Machine with jail freezes after random amount of time Message-ID: <200906081714.n58HEKfY006181@freefall.freebsd.org> Old Synopsis: [jail] [hang] Machine with jail freezes after random amount of time New Synopsis: [hang] Machine with jail freezes after random amount of time Responsible-Changed-From-To: freebsd-jail->freebsd-net Responsible-Changed-By: bz Responsible-Changed-When: Mon Jun 8 17:12:41 UTC 2009 Responsible-Changed-Why: This does not sounds like a jail but more a networking/tcp problem with 7.2-R hanging the machine. Re-assign so that the right people will look at it. http://www.freebsd.org/cgi/query-pr.cgi?pr=134583 From bz at FreeBSD.org Mon Jun 8 17:25:43 2009 From: bz at FreeBSD.org (bz@FreeBSD.org) Date: Mon Jun 8 17:25:49 2009 Subject: kern/132092: [jail] jail can listen on *:port when jail_socket_unixiproute_only set to NO Message-ID: <200906081725.n58HPgV1013193@freefall.freebsd.org> Synopsis: [jail] jail can listen on *:port when jail_socket_unixiproute_only set to NO Responsible-Changed-From-To: freebsd-jail->bz Responsible-Changed-By: bz Responsible-Changed-When: Mon Jun 8 17:25:24 UTC 2009 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=132092 From bz at FreeBSD.org Mon Jun 8 17:30:10 2009 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Mon Jun 8 17:30:16 2009 Subject: kern/133265: [jail] is there a solution how to run nfs client in jail environment? Message-ID: <200906081730.n58HU939013478@freefall.freebsd.org> The following reply was made to PR kern/133265; it has been noted by GNATS. From: "Bjoern A. Zeeb" To: bug-followup@FreeBSD.org, pg@fincombank.com Cc: Subject: Re: kern/133265: [jail] is there a solution how to run nfs client in jail environment? Date: Mon, 8 Jun 2009 17:18:35 +0000 (UTC) The general answer is: it is not possible. You could do the NFS mount from the base system and have the mountpoint within the visbility of the jail. You may get around enabling raw_sockets but if that works somehow I wouldn't rely on it and you'll have to be aware of what globally enabling raw sockets means. With FreeBSD 8 it will hopefully be possible as you may have your own network stack oer jail. I am just not sure if the NFS code is there ("fully virtualized") yet to make it work. -- Bjoern A. Zeeb The greatest risk is not taking one. From ltning at anduin.net Mon Jun 8 17:57:14 2009 From: ltning at anduin.net (=?ISO-8859-1?Q?Eirik_=D8verby?=) Date: Mon Jun 8 17:58:27 2009 Subject: kern/133265: [jail] is there a solution how to run nfs client in jail environment? In-Reply-To: <200906081730.n58HU939013478@freefall.freebsd.org> References: <200906081730.n58HU939013478@freefall.freebsd.org> Message-ID: Hoi, someone (Landon) did a java16 build on one of our sparc64 jails using NFS in some way for cross-building elsewhere and stuff. Some userland NFS from ports, I believe. Just fyi. /Eirik On 8. juni. 2009, at 19.30, Bjoern A. Zeeb wrote: > The following reply was made to PR kern/133265; it has been noted by > GNATS. > > From: "Bjoern A. Zeeb" > To: bug-followup@FreeBSD.org, pg@fincombank.com > Cc: > Subject: Re: kern/133265: [jail] is there a solution how to run nfs > client > in jail environment? > Date: Mon, 8 Jun 2009 17:18:35 +0000 (UTC) > > The general answer is: it is not possible. > > You could do the NFS mount from the base system and have the > mountpoint within the visbility of the jail. > > You may get around enabling raw_sockets but if that works somehow I > wouldn't rely on it and you'll have to be aware of what globally > enabling raw sockets means. > > With FreeBSD 8 it will hopefully be possible as you may have your own > network stack oer jail. I am just not sure if the NFS code is there > ("fully virtualized") yet to make it work. > > -- > Bjoern A. Zeeb The greatest risk is not taking > one. > _______________________________________________ > 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" > From eshao at andrew.cmu.edu Wed Jun 10 01:15:26 2009 From: eshao at andrew.cmu.edu (Edwin Shao) Date: Wed Jun 10 01:15:32 2009 Subject: sysctl variables not propagating to children jails Message-ID: <17ca67550906091744p55fe0748h8f39bb326b05b06f@mail.gmail.com> Hi, In the most recent -current, I've noticed that sysctl variables no longer propagate to jails and thus it is impossible to allow raw sockets, allow mounting, etc. This might be related to . For example, in parent: hyper ~> sysctl security security.jail.param.cpuset.id: 0 security.jail.param.host.hostid: 0 security.jail.param.host.hostuuid: 64 security.jail.param.host.domainname: 256 security.jail.param.host.hostname: 256 security.jail.param.enforce_statfs: 0 security.jail.param.securelevel: 0 security.jail.param.path: 1024 security.jail.param.name: 256 security.jail.param.parent: 0 security.jail.param.jid: 0 security.jail.enforce_statfs: 2 security.jail.mount_allowed: 1 security.jail.chflags_allowed: 0 security.jail.allow_raw_sockets: 1 security.jail.sysvipc_allowed: 0 security.jail.socket_unixiproute_only: 1 security.jail.set_hostname_allowed: 0 security.jail.jail_max_af_ips: 255 security.jail.jailed: 0 In child: t# sysctl security security.jail.param.cpuset.id: 0 security.jail.param.host.hostid: 0 security.jail.param.host.hostuuid: 64 security.jail.param.host.domainname: 256 security.jail.param.host.hostname: 256 security.jail.param.enforce_statfs: 0 security.jail.param.securelevel: 0 security.jail.param.path: 1024 security.jail.param.name: 256 security.jail.param.parent: 0 security.jail.param.jid: 0 security.jail.enforce_statfs: 0 security.jail.mount_allowed: 0 security.jail.chflags_allowed: 0 security.jail.allow_raw_sockets: 0 security.jail.sysvipc_allowed: 0 security.jail.socket_unixiproute_only: 1 security.jail.set_hostname_allowed: 1 security.jail.jail_max_af_ips: 255 security.jail.jailed: 1 security.bsd.suser_enabled: 1 security.bsd.unprivileged_proc_debug: 1 security.bsd.conservative_signals: 1 security.bsd.see_other_gids: 1 security.bsd.see_other_uids: 1 security.bsd.unprivileged_read_msgbuf: 1 security.bsd.hardlink_check_gid: 0 security.bsd.hardlink_check_uid: 0 security.bsd.unprivileged_get_quota: 0 In my messages log: 944 Jun 9 20:10:26 hyper root: /etc/rc.d/jail: DEBUG: checkyesno: jail_enable is set to YES. 945 Jun 9 20:10:26 hyper root: /etc/rc.d/jail: DEBUG: run_rc_command: doit: jail_start 946 Jun 9 20:10:26 hyper root: /etc/rc.d/jail: DEBUG: checkyesno: jail_set_hostname_allow is set to NO. 947 Jun 9 20:10:26 hyper root: /etc/rc.d/jail: DEBUG: checkyesno: jail_socket_unixiproute_only is set to YES. 948 Jun 9 20:10:27 hyper root: /etc/rc.d/jail: DEBUG: checkyesno: jail_sysvipc_allow is set to NO. 949 Jun 9 20:10:27 hyper root: /etc/rc.d/jail: DEBUG: t devfs enable: YES 950 Jun 9 20:10:27 hyper root: /etc/rc.d/jail: DEBUG: t fdescfs enable: YES 951 Jun 9 20:10:27 hyper root: /etc/rc.d/jail: DEBUG: t procfs enable: YES 952 Jun 9 20:10:27 hyper root: /etc/rc.d/jail: DEBUG: t mount enable: YES 953 Jun 9 20:10:27 hyper root: /etc/rc.d/jail: DEBUG: t hostname: t 954 Jun 9 20:10:27 hyper root: /etc/rc.d/jail: DEBUG: t ip: 10.0.0.10 955 Jun 9 20:10:27 hyper root: /etc/rc.d/jail: DEBUG: t interface: 956 Jun 9 20:10:27 hyper root: /etc/rc.d/jail: DEBUG: t fib: 957 Jun 9 20:10:27 hyper root: /etc/rc.d/jail: DEBUG: t root: /usr/jails/t 958 Jun 9 20:10:27 hyper root: /etc/rc.d/jail: DEBUG: t devdir: /usr/jails/t/dev 959 Jun 9 20:10:27 hyper root: /etc/rc.d/jail: DEBUG: t fdescdir: /usr/jails/t/dev/fd 960 Jun 9 20:10:27 hyper root: /etc/rc.d/jail: DEBUG: t procdir: /usr/jails/t/proc 961 Jun 9 20:10:27 hyper root: /etc/rc.d/jail: DEBUG: t ruleset: devfsrules_jail 962 Jun 9 20:10:27 hyper root: /etc/rc.d/jail: DEBUG: t fstab: /etc/fstab.t 963 Jun 9 20:10:27 hyper root: /etc/rc.d/jail: DEBUG: t consolelog: /var/log/jail_t_console.log 964 Jun 9 20:10:27 hyper root: /etc/rc.d/jail: DEBUG: t exec start: /bin/sh /etc/rc 965 Jun 9 20:10:27 hyper root: /etc/rc.d/jail: DEBUG: t exec stop: 966 Jun 9 20:10:27 hyper root: /etc/rc.d/jail: DEBUG: t flags: -l -U root 967 Jun 9 20:10:27 hyper root: /etc/rc.d/jail: DEBUG: t consolelog: /var/log/jail_t_console.log This is using: hyper ~> uname -a FreeBSD hyper.nekogiri.com 8.0-CURRENT FreeBSD 8.0-CURRENT #0 r193627: Sun Jun 7 06:11:17 EDT 2009 root@hyper.nekogiri.com:/usr/obj/usr/home/eshao/wsp/freebsd/src/sys/XENNEKO i386 I noticed this problem when upgrading past this revision: http://svn.freebsd.org/viewvc/base?view=revision&revision=192895 Please let me know if I'm doing something stupid! Or if you need more debugging output.. Thanks, Edwin From bzeeb-lists at lists.zabbadoz.net Wed Jun 10 07:35:08 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Jun 10 07:35:15 2009 Subject: sysctl variables not propagating to children jails In-Reply-To: <17ca67550906091744p55fe0748h8f39bb326b05b06f@mail.gmail.com> References: <17ca67550906091744p55fe0748h8f39bb326b05b06f@mail.gmail.com> Message-ID: <20090610072311.K22887@maildrop.int.zabbadoz.net> On Tue, 9 Jun 2009, Edwin Shao wrote: Hi, > In the most recent -current, I've noticed that sysctl variables no > longer propagate to jails and thus it is impossible to allow raw > sockets, allow mounting, etc. This might be related to > . .. > Please let me know if I'm doing something stupid! No, nothing apart from probably not spotting that the problem was already well understood and there had been workarounds suggested at the end of the above thread. That said, expect the problem to be fixed within 24 hours. You will only have to rebuild your jail(8) command line tool, once you spot the commit by: 1) update your source and make sure to have the new version of jail.c 2) cd src/usr.sbin/jail 3) make obj && make depend && make all 4) sudo make install 5) try again. In case you still see problems afterwards, cry again, loud and in here - in case that will fix the problem a short note will be welcome as well;-) /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From jamie at FreeBSD.org Wed Jun 10 15:49:33 2009 From: jamie at FreeBSD.org (Jamie Gritton) Date: Wed Jun 10 15:49:44 2009 Subject: sysctl variables not propagating to children jails In-Reply-To: <20090610072311.K22887@maildrop.int.zabbadoz.net> References: <17ca67550906091744p55fe0748h8f39bb326b05b06f@mail.gmail.com> <20090610072311.K22887@maildrop.int.zabbadoz.net> Message-ID: <4A2FD117.2040902@FreeBSD.org> Bjoern A. Zeeb wrote: > On Tue, 9 Jun 2009, Edwin Shao wrote: > > Hi, > >> In the most recent -current, I've noticed that sysctl variables no >> longer propagate to jails and thus it is impossible to allow raw >> sockets, allow mounting, etc. This might be related to >> . > .. >> Please let me know if I'm doing something stupid! > > No, nothing apart from probably not spotting that the problem was > already well understood and there had been workarounds suggested at > the end of the above thread. > > > That said, expect the problem to be fixed within 24 hours. You will > only have to rebuild your jail(8) command line tool, once you spot the > commit by: > > 1) update your source and make sure to have the new version of jail.c > 2) cd src/usr.sbin/jail > 3) make obj && make depend && make all > 4) sudo make install > 5) try again. > > In case you still see problems afterwards, cry again, loud and in > here - in case that will fix the problem a short note will be > welcome as well;-) The patch is now in for this - recompile jail(8) with r193929. - Jamie From bugmaster at FreeBSD.org Mon Jun 15 11:06:58 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 15 11:08:34 2009 Subject: Current problem reports assigned to freebsd-jail@FreeBSD.org Message-ID: <200906151106.n5FB6v8R076966@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 Jun 22 11:06:59 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 22 11:08:35 2009 Subject: Current problem reports assigned to freebsd-jail@FreeBSD.org Message-ID: <200906221106.n5MB6v4G018077@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 spermine at uniceltech.com Tue Jun 23 20:07:02 2009 From: spermine at uniceltech.com (bookmakers) Date: Tue Jun 23 20:07:09 2009 Subject: Should You Reveal Your sexual History - Trruth Vss Ignorance? Message-ID: <430b6a211a20090623200405@post.dbunet.dk> Snhould You Reveal Your sexual History - Truth Vs Ignoranyce? www . shop94 . net From tomh at motorsport.com Tue Jun 23 20:27:20 2009 From: tomh at motorsport.com (Tom Haapanen) Date: Tue Jun 23 20:27:27 2009 Subject: Memory usage across multiple jails Message-ID: <0c1201c9f43e$166c8450$43458cf0$@com> I have been using FreeBSD (and other forms of *BSD) a long time, but I'm new to the world of jails. I have been doing reading on them, but there is one question I have not been able to find an answer to, and that's the efficiency of memory usage when using multiple jails on a single system. With "conventional" virtual machines (VMware, Virtual Server et al), essentially each VM is opaque to the host OS, and thus has to be allocated X MB of memory, which that VM then manages internally. However, since jails are based on the FreeBSD kernel, and both host and guest OSs are identical, I am wondering whether there are any comparative efficiencies in memory utilization. Will the jails share the disk cache, for example, or does each jail allocate its own? Will other kernel structures (and code!) be shared across jails, or allocated multiple times? And what about userland applications, like httpd, for example? (I suspect userland would not be able to benefit, but that's just a guess.) Thanks for any insight into this ... Tom From scheidell at secnap.net Tue Jun 23 21:17:12 2009 From: scheidell at secnap.net (Michael Scheidell) Date: Tue Jun 23 21:17:19 2009 Subject: Memory usage across multiple jails In-Reply-To: <0c1201c9f43e$166c8450$43458cf0$@com> References: <0c1201c9f43e$166c8450$43458cf0$@com> Message-ID: <4A41417A.9080805@secnap.net> Tom Haapanen wrote: > I have been using FreeBSD (and other forms of *BSD) a long time, but I'm new > to the world of jails. I have been doing reading on them, but there is one > question I have not been able to find an answer to, and that's the > efficiency of memory usage when using multiple jails on a single system. > > > > With "conventional" virtual machines (VMware, Virtual Server et al), > essentially each VM is opaque to the host OS, and thus has to be allocated X > MB of memory, which that VM then manages internally. > > > im been expermenting with some of this disk cache (malloc, etc) is shared. if httpd is different in each jail (even if its the same), then example: jail 1 has 4 httpd's running, one copy (of binary) will be in memory, 4 copies of data structure jail 2 has 10 httpd's running, its got one (more) copy of binary, and 10 copies of data structure. HOWEVER if you nullmount /usr/local/bin ../sbin .../libexec ../lib then you CAN share the one httpd binary. other issue is static libs. in /usr/lib these aren't likely shares, as when you build the jail, you made COPIES of /usr/lib so, nullfs mount /usr/lib /usr/bin /usr/sbin /sbin, /usr/libexec, maybe you can get the most out of it. (but, 6 freebsd jails use a heck of a lot ram than 6 vmware images) > However, since jails are based on the FreeBSD kernel, and both host and > guest OSs are identical, I am wondering whether there are any comparative > efficiencies in memory utilization. Will the jails share the disk cache, > for example, or does each jail allocate its own? Will other kernel > structures (and code!) be shared across jails, or allocated multiple times? > And what about userland applications, like httpd, for example? (I suspect > userland would not be able to benefit, but that's just a guess.) > > > > Thanks for any insight into this ... > > > > Tom > > _______________________________________________ > 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" > -- 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 andrew at modulus.org Tue Jun 23 21:17:58 2009 From: andrew at modulus.org (Andrew Snow) Date: Tue Jun 23 21:18:05 2009 Subject: Memory usage across multiple jails In-Reply-To: <0c1201c9f43e$166c8450$43458cf0$@com> References: <0c1201c9f43e$166c8450$43458cf0$@com> Message-ID: <4A41461D.4000009@modulus.org> Tom Haapanen wrote: > I am wondering whether there are any comparative > efficiencies in memory utilization. Will the jails share the disk cache, > for example, or does each jail allocate its own? Will other kernel > structures (and code!) be shared across jails, or allocated multiple times? > And what about userland applications, like httpd, for example? (I suspect > userland would not be able to benefit, but that's just a guess.) It is extremely efficient. It is as if the host system sees a single system with the processes of all the jails running. * the jails share disk cache * jails don't have any reserved memory so any unused memory returns to the free pool of the kernel, available for disk cache * there is a single kernel shared across all jails * userland code can also be shared across jails *if* you run the code from the same set of on-disk binaries (which is not the way most people set up jails) * since there is only a single kernel all network and disk I/O from the jails goes at the same speed as the host However, VMware installations are now able to achieve the same level of efficiency using the following measures: * "transparent page sharing" stores only a single copy of shared memory pages * free and unused memory in each guest can be used by installing the vmmemctl driver (part of VMware-tools) * disk cache can be "shared" by using shared storage (NAS) * paravirtualisation drivers for disk and networking in the guest can achieve full host speed & efficiency - Andrew From tomh at motorsport.com Wed Jun 24 12:47:33 2009 From: tomh at motorsport.com (Tom Haapanen) Date: Wed Jun 24 12:47:40 2009 Subject: Memory usage across multiple jails In-Reply-To: <4A41461D.4000009@modulus.org> References: <0c1201c9f43e$166c8450$43458cf0$@com> <4A41461D.4000009@modulus.org> Message-ID: <0c9201c9f4c9$ec3d1640$c4b742c0$@com> Andrew Snow wrote: > * the jails share disk cache > * jails don't have any reserved memory so any unused memory returns to > the free pool of the kernel, available for disk cache > * there is a single kernel shared across all jails > * userland code can also be shared across jails *if* you run the code > from the same set of on-disk binaries (which is not the way most people > set up jails) > * since there is only a single kernel all network and disk I/O from the > jails goes at the same speed as the host Thanks, Andrew (and Michael) -- that sounds very good. It certainly looks like I should be able to achieve some resource efficiencies this way vs running multiple physical servers. I'm also further educated about VMware ... though that's less important for me at the moment as I would really prefer to run the host on FreeBSD as well (and I suspect those required guest drivers aren't available for FreeBSD, either). Tom From ltning at anduin.net Wed Jun 24 12:55:10 2009 From: ltning at anduin.net (=?iso-8859-1?Q?Eirik_=D8verby?=) Date: Wed Jun 24 12:55:16 2009 Subject: Memory usage across multiple jails In-Reply-To: <0c9201c9f4c9$ec3d1640$c4b742c0$@com> References: <0c1201c9f43e$166c8450$43458cf0$@com> <4A41461D.4000009@modulus.org> <0c9201c9f4c9$ec3d1640$c4b742c0$@com> Message-ID: On 24. juni 2009, at 14.47, Tom Haapanen wrote: > Andrew Snow wrote: >> * the jails share disk cache >> * jails don't have any reserved memory so any unused memory returns >> to >> the free pool of the kernel, available for disk cache >> * there is a single kernel shared across all jails >> * userland code can also be shared across jails *if* you run the code >> from the same set of on-disk binaries (which is not the way most >> people >> set up jails) >> * since there is only a single kernel all network and disk I/O from >> the >> jails goes at the same speed as the host > > Thanks, Andrew (and Michael) -- that sounds very good. It certainly > looks > like I should be able to achieve some resource efficiencies this way > vs > running multiple physical servers. We are running a number of high-volume services on jails, and have been doing so since the days of FreeBSD 4.x. The hardware utilization has always been good, and has gotten significantly better with each of the releases of FreeBSD 6.x and, now, 7.x. > I'm also further educated about VMware ... though that's less > important for > me at the moment as I would really prefer to run the host on FreeBSD > as well > (and I suspect those required guest drivers aren't available for > FreeBSD, > either). No VMware running on top of another OS is going to perform anywhere near satisfactory. You'll need ESX or something else running on the bare iron (XEN?) to get anywhere near what jails (FreeBSD), vservers (Linux), zones (Solaris) etc. will give you. Of course it could be argued that the levels of separation and resource control will be different (sometimes better) with emulators, but in no other way than the intimacy of the host<->jail coupling on FreeBSD give you significant benefits too. For example, (security) auditing of jails can be done on the host, and the host can be considered a separate machine from the jails for most intents and purposes. For compliance (PCI-DSS) it is quite perfect. /Eirik From scheidell at secnap.net Wed Jun 24 21:38:10 2009 From: scheidell at secnap.net (Michael Scheidell) Date: Wed Jun 24 21:38:17 2009 Subject: tracking down problem: kill won't inside a jail Message-ID: <4A429CD2.3030302@secnap.net> I am tracking down a problem, inside a 7.1 amd64 jail, kill won't work (default -TERM) kill -QUIT does. outside of jail, TERM works fine on same box, and I have verified that same binaries and libraries are in use (i think) newly created 7.1 amd64 jails (used ezjail.. don't know if they has any issues) /etc/rc.d/cron stop won't (that is just the symptoms I have been able to track down). hardly anything will stop with TERM. by default, rc.subr (and kill) uses SIGTERM, so I do a: /etc/rc.d/cron stop and I get (60 seconds of this: /etc/rc.d/cron stop Stopping cron. Waiting for PIDS: 98104, 98104, 98104, 98104 (so, of course, if you reboot the system, and have 15 jails, all with cron, none of the stop, and it times out) going to another tty and typeing: kill 98104 doen't help kill -TERM 98104 doesn't help state is: ps -auxwwp 98104 USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 98104 0.0 0.0 6692 1228 ?? SsJ 5:20PM 0:00.01 /usr/sbin/cron -s ps -auxwwp 98104 USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 98104 0.0 0.0 6692 1228 ?? IsJ 5:20PM 0:00.01 /usr/sbin/cron -s kill -QUIT 98104 does! (so does INT, again, inside jail, I need SIGQUIT, or INT outside, default TERM works also, /etc/rc.d/cron start && sleep 2 && /etc/rc.d/cron stop seems to work but sleep 60 seconds or more and it doesn't stop anymore. outside jail, cron ps looks like this: ps -auxwwp 98197 USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 98197 0.0 0.0 6692 1116 ?? Is 5:21PM 0:00.01 /usr/sbin/cron -s inside: (I guess the J means in jail? root 98104 0.0 0.0 6692 1228 ?? SsJ 5:20PM 0:00.01 /usr/sbin/cron -s ps -auxwwp 98104 USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 98104 0.0 0.0 6692 1228 ?? IsJ 5:20PM 0:00.01 /usr/sbin/cron -s where do I start looking? id hate to put hundreds of /etc/rc.conf.d files with sigstop=SIGQUIT in just to workaround it. -- 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 Alexander at Leidinger.net Sat Jun 27 10:40:58 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sat Jun 27 10:41:06 2009 Subject: Switching /etc/rc.d/jail to new syntax (+ new features) Message-ID: <20090627122519.00002b84@unknown> Hi, 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. Bye, Alexander. From bzeeb-lists at lists.zabbadoz.net Sat Jun 27 11:05:57 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sat Jun 27 11:06:11 2009 Subject: Switching /etc/rc.d/jail to new syntax (+ new features) In-Reply-To: <20090627122519.00002b84@unknown> References: <20090627122519.00002b84@unknown> Message-ID: <20090627104704.Y22887@maildrop.int.zabbadoz.net> On Sat, 27 Jun 2009, 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 2) it's not a poper solution /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From Alexander at Leidinger.net Sat Jun 27 12:08:18 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sat Jun 27 12:08:24 2009 Subject: Switching /etc/rc.d/jail to new syntax (+ new features) In-Reply-To: <20090627104704.Y22887@maildrop.int.zabbadoz.net> References: <20090627122519.00002b84@unknown> <20090627104704.Y22887@maildrop.int.zabbadoz.net> Message-ID: <20090627140803.00006830@unknown> On Sat, 27 Jun 2009 10:47:47 +0000 (UTC) "Bjoern A. Zeeb" wrote: > On Sat, 27 Jun 2009, 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. > 2) it's not a poper solution The proper solution for the statfs part would be, that jail(8) defaults to =2 if nothing is specified. Alternatively I can get convinced that we should do a default for it in defaults/rc.conf if nothing is specied for startparams for a particular jail (like we have for some other things), but this would not be as good as if jail(8) would handle it itself. If you do not talk about the statfs part but in a more generic way, what would be a proper solution in your eyes? Bye, Alexander. From bz at FreeBSD.org Sat Jun 27 12:40:58 2009 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Sat Jun 27 12:41:04 2009 Subject: Switching /etc/rc.d/jail to new syntax (+ new features) In-Reply-To: <20090627140803.00006830@unknown> References: <20090627122519.00002b84@unknown> <20090627104704.Y22887@maildrop.int.zabbadoz.net> <20090627140803.00006830@unknown> Message-ID: <20090627121818.P22887@maildrop.int.zabbadoz.net> On Sat, 27 Jun 2009, Alexander Leidinger wrote: > On Sat, 27 Jun 2009 10:47:47 +0000 (UTC) "Bjoern A. Zeeb" > wrote: > > >> On Sat, 27 Jun 2009, 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, ... >> 2) it's not a poper solution > > The proper solution for the statfs part would be, that jail(8) defaults > to =2 if nothing is specified. Alternatively I can get convinced that > we should do a default for it in defaults/rc.conf if nothing is specied > for startparams for a particular jail (like we have for some other > things), but this would not be as good as if jail(8) would handle it > itself. > > If you do not talk about the statfs part but in a more generic way, > what would be a proper solution in your eyes? A proper solution would be a proper mgmt system ready for the future instead of continuting to hack up rc.d/jail via option fo bar baz and another 17000 of them. But this is nothing I'll discuss today while things aren't fully shaken out yet. For now what used to work should continue to work and not break. Everything else on top of that needs to be done properly and not in a rainy-midnight-drive-by. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From Alexander at Leidinger.net Sat Jun 27 14:24:37 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sat Jun 27 14:24:44 2009 Subject: Switching /etc/rc.d/jail to new syntax (+ new features) In-Reply-To: <20090627121818.P22887@maildrop.int.zabbadoz.net> References: <20090627122519.00002b84@unknown> <20090627104704.Y22887@maildrop.int.zabbadoz.net> <20090627140803.00006830@unknown> <20090627121818.P22887@maildrop.int.zabbadoz.net> Message-ID: <20090627162424.00007289@unknown> On Sat, 27 Jun 2009 12:21:09 +0000 (UTC) "Bjoern A. Zeeb" wrote: > On Sat, 27 Jun 2009, Alexander Leidinger wrote: > > > On Sat, 27 Jun 2009 10:47:47 +0000 (UTC) "Bjoern A. Zeeb" > > wrote: > > > > > >> On Sat, 27 Jun 2009, 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. > >> 2) it's not a poper solution > > > > The proper solution for the statfs part would be, that jail(8) > > defaults to =2 if nothing is specified. Alternatively I can get > > convinced that we should do a default for it in defaults/rc.conf if > > nothing is specied for startparams for a particular jail (like we > > have for some other things), but this would not be as good as if > > jail(8) would handle it itself. > > > > If you do not talk about the statfs part but in a more generic way, > > what would be a proper solution in your eyes? > > A proper solution would be a proper mgmt system ready for the future > instead of continuting to hack up rc.d/jail via option fo bar baz and > another 17000 of them. > But this is nothing I'll discuss today while things aren't fully > shaken out yet. And I assume from what you say, that such a new mgmt system will not be ready for 8.0. Whatever it will be, it sounds like it will be different from what we have ATM, so I don't think it will be something which will replace the current approach in 8-stable, but will be available additionally, if at all. > For now what used to work should continue to work and not break. > Everything else on top of that needs to be done properly and not in a > rainy-midnight-drive-by. This is not a drive-by. I provide a patch for discussion which allows to use some new features in 8.0 which doesn't break when someone updates from 7.x. Some small enhancement which doesn't break backwards compatibility is always better than no improvement at all. It may not handle all cases, but for this reason I ask people to test it. After that some things can maybe fixed, and after that it can be evaluated if it is worth to commit or not. I don't even urge to rush this in before 8.0. I just offer it now, so that people can actually use some new features. I had to write this anyway, as without the new syntax I wouldn't have been able to use my enhancement to run X in a jail, which I ported to the new syntax. If people think it is useful for 8.0 and nothing better is available for 8.0, it should be shipped with 8.0 IMO (if nothing breaks), but if it isn't, I don't care, as I have it for where I need it. Bye, Alexander. From bugmaster at FreeBSD.org Mon Jun 29 11:07:02 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 29 11:08:34 2009 Subject: Current problem reports assigned to freebsd-jail@FreeBSD.org Message-ID: <200906291107.n5TB71Xj046384@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 bzeeb-lists at lists.zabbadoz.net Mon Jun 29 11:30:09 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Mon Jun 29 11:30:21 2009 Subject: Can't login Jailed system In-Reply-To: <736c47cb0906290422y756a6a74i9029b4d27d2ade34@mail.gmail.com> References: <736c47cb0906290422y756a6a74i9029b4d27d2ade34@mail.gmail.com> Message-ID: <20090629112655.R22887@maildrop.int.zabbadoz.net> On Mon, 29 Jun 2009, Sam Wun wrote: Hi, we've got a freebsd-jail list that I am Cc:ing. > With FreeBSD 7.2Stable, > I have done this many times before. > After about a month left the "jail" behind, now when I done a > "/etc/rc.d/jail start" and ssh into it, I ended up login to the host > system. > Here is the network configuraiton of the host system and the jail system: > > # ifconfig > rl0: flags=8843 metric 0 mtu 1500 > options=8 > ether 00:00:21:ef:27:f7 > media: Ethernet autoselect (100baseTX ) > status: active > rl1: flags=8802 metric 0 mtu 1500 > options=8 > ether 00:50:fc:65:78:c0 > media: Ethernet autoselect > status: no carrier > fxp0: flags=8843 metric 0 mtu 1500 > options=8 > ether 00:13:20:65:a9:be > inet 192.168.1.246 netmask 0xffffff00 broadcast 192.168.1.255 > inet 192.168.1.245 netmask 0xffffff00 broadcast 192.168.1.255 > inet 192.168.1.235 netmask 0xffffff00 broadcast 192.168.1.255 > inet 192.168.1.242 netmask 0xffffffff broadcast 192.168.1.242 > media: Ethernet autoselect (100baseTX ) > status: active > plip0: flags=108810 metric 0 mtu 1500 > enc0: flags=0<> metric 0 mtu 1536 > pflog0: flags=141 metric 0 mtu 33204 > pfsync0: flags=0<> metric 0 mtu 1460 > syncpeer: 224.0.0.240 maxupd: 128 > lo0: flags=8049 metric 0 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > twp1:# jls > JID IP Address Hostname Path > 5 192.168.1.242 twp5.ip6.com.au /usr/jail2/twp5 > > 192.168.1.242 is the jailed system, > twp1 is the host system. > > After I login 192.168.1.242, I ended up logged in twp1 which is my host system. > Now I am stuck. I don't know how I logged in the jailed system a month ago. > > Can anyone shred some lights on me? Try to jexec 5 /bin/sh (5 is the jailID from the jls output) and check with ps if sshd is running inside the jail, and check the usual things are up and there. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From jon at passki.us Mon Jun 29 12:10:46 2009 From: jon at passki.us (Jon Passki) Date: Mon Jun 29 12:10:54 2009 Subject: Can't login Jailed system In-Reply-To: <20090629112655.R22887@maildrop.int.zabbadoz.net> References: <736c47cb0906290422y756a6a74i9029b4d27d2ade34@mail.gmail.com> <20090629112655.R22887@maildrop.int.zabbadoz.net> Message-ID: (Un-CC'd freebsd-net@) On Mon, Jun 29, 2009 at 6:29 AM, Bjoern A. Zeeb wrote: > On Mon, 29 Jun 2009, Sam Wun wrote: > >> After I login 192.168.1.242, I ended up logged in twp1 which is my host >> system. >> Now I am stuck. I don't know how I logged in the jailed system a month >> ago. >> >> Can anyone shred some lights on me? > > Try to jexec 5 /bin/sh (5 is the jailID from the jls output) ?and check > with ps if sshd is running inside the jail, and check the usual things > are up and there. Sam, what Bjoern is alluding to is that SSH in the main system is probably running on all IP addresses on port 22/TCP. ?The jail(8) man page has a section called "Setting up the Host Environment" which you might want to review again. For SSH, check out /etc/ssh/sshd_config and look for "ListenAddress". If it is setup for the default setting of "#ListenAddress 0.0.0.0", then uncomment it and change that line in your main system to be the main IP address. Restart sshd (/etc/rc.d/sshd restart). You will probably have to restart your jail's sshd instances since they probably tried to bind to their IP address on 22/TCP unsuccessfully. (Or, just restart all of your jails if it's not a big concern, /etc/rc.d/jail restart.) Hope that helps, Jon From jon at passki.us Mon Jun 29 14:29:57 2009 From: jon at passki.us (Jon Passki) Date: Mon Jun 29 14:30:03 2009 Subject: Can't login Jailed system In-Reply-To: <736c47cb0906290721o29875356pddf7eab455324b0@mail.gmail.com> References: <736c47cb0906290422y756a6a74i9029b4d27d2ade34@mail.gmail.com> <20090629112655.R22887@maildrop.int.zabbadoz.net> <736c47cb0906290721o29875356pddf7eab455324b0@mail.gmail.com> Message-ID: On Mon, Jun 29, 2009 at 9:21 AM, Sam Wun wrote: > I got the following errors now: > > # less jail_wwp1_console.log > ps: empty file: Invalid argument > Loading configuration files. > /etc/rc: WARNING: $hostname is not set -- see rc.conf(5). > ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib > /usr/local/lib/mysql > a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout > Creating and/or trimming log files:. > Starting syslogd. > Clearing /tmp. > Starting local daemons:. > Updating motd. > Starting sshd. > PRNG is not seeded > Starting cron. > Local package initialization:. > ps: bad namelist Assuming you didn't build a kernel to exclude the random device, it looks like you do not have a /dev filesystem mounted for your jail. ssh needs some type of random device. Try mounting a devfs in the path of your jail. If you are using /etc/rc.conf for this information, man 5 rc.conf, look at the "jail_devfs_enable" and "jail__devfs_enable" variables. Jon From swun2010 at gmail.com Mon Jun 29 14:37:30 2009 From: swun2010 at gmail.com (Sam Wun) Date: Mon Jun 29 14:37:36 2009 Subject: Can't login Jailed system In-Reply-To: References: <736c47cb0906290422y756a6a74i9029b4d27d2ade34@mail.gmail.com> <20090629112655.R22887@maildrop.int.zabbadoz.net> <736c47cb0906290721o29875356pddf7eab455324b0@mail.gmail.com> Message-ID: <736c47cb0906290737g34390ab8l8d86e437cbf9f833@mail.gmail.com> Apologies, I accidentally commented out the jail_dev and jail_proc liens in the rc.conf file, wasted everyone s time. Thanks for the help. :D Sam On Tue, Jun 30, 2009 at 12:29 AM, Jon Passki wrote: > On Mon, Jun 29, 2009 at 9:21 AM, Sam Wun wrote: >> I got the following errors now: >> >> # less jail_wwp1_console.log >> ps: empty file: Invalid argument >> Loading configuration files. >> /etc/rc: WARNING: $hostname is not set -- see rc.conf(5). >> ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib >> /usr/local/lib/mysql >> a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout >> Creating and/or trimming log files:. >> Starting syslogd. >> Clearing /tmp. >> Starting local daemons:. >> Updating motd. >> Starting sshd. >> PRNG is not seeded >> Starting cron. >> Local package initialization:. >> ps: bad namelist > > Assuming you didn't build a kernel to exclude the random device, it > looks like you do not have a /dev filesystem mounted for your jail. > ssh needs some type of random device. ?Try mounting a devfs in the > path of your jail. ?If you are using /etc/rc.conf for this > information, man 5 rc.conf, look at the "jail_devfs_enable" and > "jail__devfs_enable" variables. > > Jon > From swun2010 at gmail.com Mon Jun 29 14:52:14 2009 From: swun2010 at gmail.com (Sam Wun) Date: Mon Jun 29 14:52:20 2009 Subject: Can't login Jailed system In-Reply-To: References: <736c47cb0906290422y756a6a74i9029b4d27d2ade34@mail.gmail.com> <20090629112655.R22887@maildrop.int.zabbadoz.net> Message-ID: <736c47cb0906290721o29875356pddf7eab455324b0@mail.gmail.com> I got the following errors now: # less jail_wwp1_console.log ps: empty file: Invalid argument Loading configuration files. /etc/rc: WARNING: $hostname is not set -- see rc.conf(5). ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/mysql a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout Creating and/or trimming log files:. Starting syslogd. Clearing /tmp. Starting local daemons:. Updating motd. Starting sshd. PRNG is not seeded Starting cron. Local package initialization:. ps: bad namelist THANKS From jamie at FreeBSD.org Mon Jun 29 17:43:44 2009 From: jamie at FreeBSD.org (Jamie Gritton) Date: Mon Jun 29 17:43:51 2009 Subject: Switching /etc/rc.d/jail to new syntax (+ new features) In-Reply-To: <20090627162424.00007289@unknown> References: <20090627122519.00002b84@unknown> <20090627104704.Y22887@maildrop.int.zabbadoz.net> <20090627140803.00006830@unknown> <20090627121818.P22887@maildrop.int.zabbadoz.net> <20090627162424.00007289@unknown> Message-ID: <4A48FA49.70600@FreeBSD.org> 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. 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). He still has the larger disagreements he mentioned though, so I'm working now toward a more comprehensive solution. >>>> 2) it's not a poper solution >>>> >>> The proper solution for the statfs part would be, that jail(8) >>> defaults to =2 if nothing is specified. Alternatively I can get >>> convinced that we should do a default for it in defaults/rc.conf if >>> nothing is specied for startparams for a particular jail (like we >>> have for some other things), but this would not be as good as if >>> jail(8) would handle it itself. >>> >>> If you do not talk about the statfs part but in a more generic way, >>> what would be a proper solution in your eyes? >>> >> A proper solution would be a proper mgmt system ready for the future >> instead of continuting to hack up rc.d/jail via option fo bar baz and >> another 17000 of them. >> But this is nothing I'll discuss today while things aren't fully >> shaken out yet. >> > > And I assume from what you say, that such a new mgmt system will not be > ready for 8.0. Whatever it will be, it sounds like it will be different > from what we have ATM, so I don't think it will be something which will > replace the current approach in 8-stable, but will be available > additionally, if at all. > > >> For now what used to work should continue to work and not break. >> Everything else on top of that needs to be done properly and not in a >> rainy-midnight-drive-by. >> > > This is not a drive-by. I provide a patch for discussion which allows > to use some new features in 8.0 which doesn't break when someone > updates from 7.x. Some small enhancement which doesn't break backwards > compatibility is always better than no improvement at all. It may not > handle all cases, but for this reason I ask people to test it. After > that some things can maybe fixed, and after that it can be evaluated if > it is worth to commit or not. > > I don't even urge to rush this in before 8.0. I just offer it now, so > that people can actually use some new features. I had to write this > anyway, as without the new syntax I wouldn't have been able to use my > enhancement to run X in a jail, which I ported to the new syntax. If > people think it is useful for 8.0 and nothing better is available for > 8.0, it should be shipped with 8.0 IMO (if nothing breaks), but if it > isn't, I don't care, as I have it for where I need it. > > Bye, > Alexander. > _______________________________________________ > 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" >