The base system has allow_raw_sockets, the first level jail also has allow_raw_sockets and has the exact same configuration as the base system (I use puppet to manage config files.) I can't set allow_raw_sockets anyway for the second-level jail without manually invoking the jail command.
On Tue, Sep 29, 2009 at 7:08 AM, Jamie Gritton <ja...@freebsd.org> wrote: > Does the base system have security.jail.allow_raw_sockets=1? You need to > have that, or set the jail's allow.raw_sockets. You can't set the jail's > permissions from within the jail itself. If you have multiple jail > levels, then both jails need to allow raw sockets - a jail can't allow a > child jail to do what it can't do itself. > > - Jamie > > > Edwin Shao wrote: > >> One other thing that is odd: hierarchical jails don't seem to inherit some >> sysctls such as allow_raw_socket. >> >> In the host (jail), rc.conf has jail_set_allow_raw_sockets="YES" and >> sysctl.conf has "security.jail.allow_raw_sockets=1", but no child jail can >> ping out: >> neko# ping google.com <http://google.com> >> ping: socket: Operation not permitted >> >> What is happening in this case? >> Thank you for your time again. >> >> >> On Tue, Sep 29, 2009 at 12:16 AM, Jamie Gritton <ja...@freebsd.org<mailto: >> ja...@freebsd.org>> wrote: >> >> The sysctls not only don't get written to, they don't have any useful >> information to read either. They only describe the existence and format >> of the various jail parameters. Sorry, but there;s no way to set a >> default children.max parameter or inherit it from the parent. We've >> decided to set the default to the most secure/restrictive in many >> cases. >> Once we've come up with a new jail configuration interface, this won't >> be such a hassle. >> >> The devfs errors are probably something that will have to be addressed >> in a later revision - I haven't looked in the devfs direction so I'm >> not >> sure about that. The mount error may be related to the first jail's >> allow.mount parameter (whose default comes from >> security.jail.mount_allowed). >> >> - Jamie >> >> Edwin Shao wrote: >> >> Thanks, that worked for me. >> >> * Using jail to change children.max on the parent does not >> affect `sysctl security.jail.param.children.max` in the child. >> Also security.jail.param.children.cur never changes either. Not >> sure if that's intended behavior. >> * Is there any way to persist the >> security.jail.param.children.max parameter without entering the >> jail command every time? * I get the following output when I >> create a jail inside a jail: >> >> hyper ~> ezjail-admin start neko >> Configuring jails:. >> Starting jails:devfs rule: ioctl DEVFSIO_RGETNEXT: Operation not >> permitted >> devfs rule: ioctl DEVFSIO_RGETNEXT: Operation not permitted >> /etc/rc.d/jail: WARNING: devfs_set_ruleset: you must specify a >> ruleset number >> devfs rule: ioctl DEVFSIO_SAPPLY: Operation not permitted >> ln: log: Operation not permitted >> mount: proc : Operation not permitted >> neko. >> >> I'm using the same configuration values as in the parent's jail, >> which work. Everything seems to work alright inside the jail, so >> I assume the errors are safe to ignore? >> >> Thanks again! >> - Edwin >> >> On Mon, Sep 28, 2009 at 9:11 PM, Bjoern A. Zeeb >> <bzeeb-li...@lists.zabbadoz.net >> <mailto:bzeeb-li...@lists.zabbadoz.net> >> <mailto:bzeeb-li...@lists.zabbadoz.net >> <mailto:bzeeb-li...@lists.zabbadoz.net>>> wrote: >> >> On Mon, 28 Sep 2009, Edwin Shao wrote: >> >> Hi Jamie, >> When I try to change the parameter, nothing happens: >> rescue /etc> sudo sysctl security.jail.param.children.max=1 >> security.jail.param.children.max: 0 -> 0 >> >> rescue /etc> sudo sysctl security.jail.param.children.max >> security.jail.param.children.max: 0 >> >> Am I doing this incorrectly? >> >> >> Yes. It's a parameter to jail(8). The security.jail.param >> sysctls can >> be seen as a list of possible options valid to jail(8). See >> man 8 jail >> for the exact details. >> >> /bz >> >> -- Bjoern A. Zeeb What was I talking about and >> who are you again? >> >> >> >> _______________________________________________ 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"