Re: sysvipc in jails + CURRENT
On Thu, 22 Jul 2010, Isaac Levy wrote: Hi ike, long time no see. I could be doing something stupid, or I've dug up an old bug, = (http://www.mail-archive.com/freebsd-jail@freebsd.org/msg00859.html). I cannot get good ol' trusty enforce_statfs to work, allowing me to see = different mounts from within a jail. -- The example jail command I'm using, (new-style), jail -c path=3D$JDIR host.hostname=3D$JHOSTNAME ip4.addr=3D"$INET" = enforce_statfs=3D1 command=3D/bin/sh /etc/rc I've tried everything- including attempting to change my sysctls over = and over, (including /etc/sysctl.conf with rebooting). Interestingly: The old standard 'security.jail.enforce_statfs' was not something I = could modify, *until* I put a sysctl value in /etc/sysctl.conf which was = not 0 (1 or 2 both will let me set the sysctl value once the system is = booted). If I have "security.jail.enforce_statfs=3D0", to my surprise, I cannot = change that sysctl on the host system as I would usually expect. (This is what makes me think this smells like a bug) My extra mounts are UFS volumes, mounted right into the jail directory, = (on another ufs volume). What follows, are just machine stats if anyone wants them? I'd love any thoughts, urls, no matter how brief... I am confused but maybe I can help you with some explanation: 1) do not change the sysctl anywhere; that is neither in sysctl.conf nor by other magic or by hand. The default on 8 and 9 should be 2. You can check that with sysctl security.jail.enforce_statfs still I think. 2) Creating a new jail > jail -c path=/jail/j1 persist I can see: > jexec 1 mount 192.168.5.1:/zoo/bz/HEAD on / (nfs) And > jls -s -j 1 enforce_statfs enforce_statfs=2 confirms the default. 3) modifying the jail: > jail -m jid=1 enforce_statfs=1 I can now see: > jexec 1 mount 192.168.5.1:/zoo/bz/HEAD on / (nfs) devfs on /dev (devfs, local, multilabel) 192.168.5.1:/zoo/bz on /zoo/bz (nfs) And jls confirms that the modfication was successful: > jls -s -j 1 enforce_statfs enforce_statfs=1 4) If you lower the default by changing the sysctl, all your jails that have a higher level will be lowered as well. 5) But if you up the default again, they won't change back up. I think that you are right, that there is a bug here, as 4) and 5) should be working the other way round I think. Anyway, the summary is: if you don't change the default a jail -c enforce_statfs=1 ... should just work fine. Hope this helps. /bz -- Bjoern A. Zeeb This signature is about you not me. ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
Re: sysvipc in jails + CURRENT
Hi All, I could be doing something stupid, or I've dug up an old bug, (http://www.mail-archive.com/freebsd-jail@freebsd.org/msg00859.html). I cannot get good ol' trusty enforce_statfs to work, allowing me to see different mounts from within a jail. -- The example jail command I'm using, (new-style), jail -c path=$JDIR host.hostname=$JHOSTNAME ip4.addr="$INET" enforce_statfs=1 command=/bin/sh /etc/rc I've tried everything- including attempting to change my sysctls over and over, (including /etc/sysctl.conf with rebooting). Interestingly: The old standard 'security.jail.enforce_statfs' was not something I could modify, *until* I put a sysctl value in /etc/sysctl.conf which was not 0 (1 or 2 both will let me set the sysctl value once the system is booted). If I have "security.jail.enforce_statfs=0", to my surprise, I cannot change that sysctl on the host system as I would usually expect. (This is what makes me think this smells like a bug) My extra mounts are UFS volumes, mounted right into the jail directory, (on another ufs volume). What follows, are just machine stats if anyone wants them? I'd love any thoughts, urls, no matter how brief... Best, .ike -- $ sysctl security.jail 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.children.max: 0 security.jail.param.children.cur: 0 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: 1 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: 0 security.jail.jail_max_af_ips: 255 security.jail.jailed: 0 -- More system stats: FreeBSD copper 8.0-RELEASE-p4 FreeBSD 8.0-RELEASE-p4 #5: Tue Jul 20 12:33:57 EDT 2010 i...@copper.vault.tab:/usr/obj/usr/src/sys/80-amd64kernMay2010 amd64 ... # ikenote: additives to generic kernel, FreeBSD 7.2->8.0: # HTTPD/DNS Accept Filter Suport # (queues requests in OS socket until entire request is in) # Applications must make use of the syscall in their implementation, # (Apache 1.x-2.x is a clear case of use). # See the man page for accept_filter(9) for more info. options ACCEPT_FILTER_HTTP options ACCEPT_FILTER_DATA options ACCEPT_FILTER_DNS #FreeBSD 8.0 onward only # ZFS ADDITIVES # http://wiki.freebsd.org/ZFSTuningGuide # or alternatively, see: /usr/src/sys/i386/conf/NOTES ##options KVA_PAGES=512 # not required on amd64 # lagg(4) link aggregation and link failover interface device lagg # PF, CARP, ALTQ... device pf device pflog device pfsync # ALTQ, network card queue offloading # see the altq(4) man page for a list of supported drivers options ALTQ options ALTQ_CBQ# Class Bases Queuing (CBQ) options ALTQ_RED# Random Early Detection (RED) options ALTQ_RIO# RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) options ALTQ_PRIQ # Priority Queuing (PRIQ) options ALTQ_NOPCC # Required for SMP build # DTRACE options KDTRACE_HOOKS options DDB_CTF options KDTRACE_FRAME # amd64 only -- dmesg -- Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-RELEASE-p4 #5: Tue Jul 20 12:33:57 EDT 2010 i...@copper.vault.tab:/usr/obj/usr/src/sys/80-amd64kernMay2010 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU E5405 @ 2.00GHz (2000.08-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x1067a Stepping = 10 Features=0xbfebfbff Features2=0x40ce33d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 34359738368 (32768 MB) avail memory = 33150808064 (31615 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 8 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) unknown: I/O range not supported Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 16 at device 0.0 on pci2
Re: sysvipc in jails + CURRENT
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. ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
Re: sysvipc in jails + CURRENT
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 r...@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-unsubscr...@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 > r...@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.41INTDB01-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 ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
Re: sysvipc in jails + CURRENT
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 r...@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-unsubscr...@freebsd.org"
sysvipc in jails + CURRENT
Hello List, 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 r...@tba.bsam.ru:/usr/obj/usr/src/sys/TBA amd64 % sysctl security.jail.sysvipc_allowed security.jail.sysvipc_allowed: 1 - WBR -- bsam ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
