Date: Mon, 28 Sep 2009 15:16:08 -0600 From: Jamie Gritton <jamie@FreeBSD.org> To: Edwin Shao <edwin.shao@gmail.com> Cc: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, freebsd-jail@FreeBSD.org Subject: Re: Tutorial for Hierarchical Jails? Message-ID: <4AC12798.8070308@FreeBSD.org> In-Reply-To: <cf8a6aa50909281326t72701481ve6b2450e792cd104@mail.gmail.com> References: <cf8a6aa50909280506g63030d9ft423c42e8c61700d@mail.gmail.com> <4AC0E5E6.1010700@FreeBSD.org> <cf8a6aa50909281045x47e58e99y92437ffa86c72846@mail.gmail.com> <20090928180731.M68375@maildrop.int.zabbadoz.net> <cf8a6aa50909281326t72701481ve6b2450e792cd104@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
The sysctls not only don't get written to, they don't have any useful information to read either. They only describe the existence and format of the various jail parameters. Sorry, but there;s no way to set a default children.max parameter or inherit it from the parent. We've decided to set the default to the most secure/restrictive in many cases. Once we've come up with a new jail configuration interface, this won't be such a hassle. The devfs errors are probably something that will have to be addressed in a later revision - I haven't looked in the devfs direction so I'm not sure about that. The mount error may be related to the first jail's allow.mount parameter (whose default comes from security.jail.mount_allowed). - Jamie Edwin Shao wrote: > Thanks, that worked for me. > > * Using jail to change children.max on the parent does not affect > `sysctl security.jail.param.children.max` in the child. Also > security.jail.param.children.cur never changes either. Not sure if > that's intended behavior. > * Is there any way to persist the security.jail.param.children.max > parameter without entering the jail command every time? > * I get the following output when I create a jail inside a jail: > > hyper ~> ezjail-admin start neko > Configuring jails:. > Starting jails:devfs rule: ioctl DEVFSIO_RGETNEXT: Operation not permitted > devfs rule: ioctl DEVFSIO_RGETNEXT: Operation not permitted > /etc/rc.d/jail: WARNING: devfs_set_ruleset: you must specify a ruleset > number > devfs rule: ioctl DEVFSIO_SAPPLY: Operation not permitted > ln: log: Operation not permitted > mount: proc : Operation not permitted > neko. > > I'm using the same configuration values as in the parent's jail, which > work. Everything seems to work alright inside the jail, so I assume the > errors are safe to ignore? > > Thanks again! > - Edwin > > On Mon, Sep 28, 2009 at 9:11 PM, Bjoern A. Zeeb > <bzeeb-lists@lists.zabbadoz.net <mailto:bzeeb-lists@lists.zabbadoz.net>> > wrote: > > On Mon, 28 Sep 2009, Edwin Shao wrote: > > Hi Jamie, > When I try to change the parameter, nothing happens: > rescue /etc> sudo sysctl security.jail.param.children.max=1 > security.jail.param.children.max: 0 -> 0 > > rescue /etc> sudo sysctl security.jail.param.children.max > security.jail.param.children.max: 0 > > Am I doing this incorrectly? > > > Yes. It's a parameter to jail(8). The security.jail.param sysctls can > be seen as a list of possible options valid to jail(8). See man 8 jail > for the exact details. > > /bz > > -- > Bjoern A. Zeeb What was I talking about and who are you again? > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4AC12798.8070308>