From owner-freebsd-jail@FreeBSD.ORG Tue Sep 29 00:07:55 2009 Return-Path: Delivered-To: freebsd-jail@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4E27106568B; Tue, 29 Sep 2009 00:07:55 +0000 (UTC) (envelope-from edwin.shao@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id 561298FC20; Tue, 29 Sep 2009 00:07:54 +0000 (UTC) Received: by yxe1 with SMTP id 1so5783370yxe.3 for ; Mon, 28 Sep 2009 17:07:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=ukwVEk/ZMYngNQQGujR7Ir8s2zAP4Wg3sgZ4anDFYHo=; b=gP812pnzUoDVd/sYozN8h8LRd+eaKCK0P+D/fsLX339X2tiQb5jYYAtFVAJ3P6WCLd qn6x+uxFI+Coigy4oWqFesfcDDTPVyrpMdqrje1tZSHUvYVv7oyjMVi1UohQO4RQw9Xo 9pmH70iTGFhe86JVVBSmVcalhGWiDSkC3/CPE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=efg4RR95grntN4B4SYr0uMANd+J10mo+wVyLFwQ81IcAUtNbGnsWpQT/qDR+q9EAy4 FgiNp/8+yHKxNBy5jEIHRJjkEaH7/KzchFTlGjJaAyipLgqYj4unOjK/VsXM2pO5zPRH rTllObkCi0AzMWFfnmPyyWqTlbHfteZFshNk8= MIME-Version: 1.0 Received: by 10.101.79.13 with SMTP id g13mr3801767anl.40.1254182872090; Mon, 28 Sep 2009 17:07:52 -0700 (PDT) In-Reply-To: <4AC12798.8070308@FreeBSD.org> References: <4AC0E5E6.1010700@FreeBSD.org> <20090928180731.M68375@maildrop.int.zabbadoz.net> <4AC12798.8070308@FreeBSD.org> From: Edwin Shao Date: Tue, 29 Sep 2009 03:07:32 +0300 Message-ID: To: Jamie Gritton Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "Bjoern A. Zeeb" , freebsd-jail@freebsd.org Subject: Re: Tutorial for Hierarchical Jails? X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 00:07:55 -0000 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 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 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-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? >> >> >>