From owner-freebsd-hackers@freebsd.org Sat Jun 16 17:32:03 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6DE8101CE3E; Sat, 16 Jun 2018 17:32:02 +0000 (UTC) (envelope-from fabian.freyer@physik.tu-berlin.de) Received: from mail.physik.tu-berlin.de (mail.physik-pool.tu-berlin.de [130.149.50.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8575068EDA; Sat, 16 Jun 2018 17:32:01 +0000 (UTC) (envelope-from fabian.freyer@physik.tu-berlin.de) Received: from [192.168.0.114] (unknown [130.149.50.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.physik.tu-berlin.de (Postfix) with ESMTPSA id 4EE0761F99; Sat, 16 Jun 2018 17:31:52 +0000 (UTC) Subject: Re: sizeof jail parameter values To: James Gritton , freebsd-jail@freebsd.org Cc: freebsd-hackers@freebsd.org References: From: Fabian Freyer Message-ID: Date: Sat, 16 Jun 2018 19:31:44 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2018 17:32:03 -0000 [reordered parts of the reply for better reading flow] On 05/18/2018 18:49, James Gritton wrote: > I would recommend skipping out on jail_getv(), which is really only > good for getting a few well-known parameters, and instead use the more > complete but more complex jailparam_init/get/export/free. Thanks! I ended up writing wrappers around the jail_get(2) and jail_set(2) interfaces and constructing the iovectors myself, which ended up quite a bit cleaner. The jailparam_{init,get,export,free} APIs are unnecessarily complex and don't seem to be a good fit (writing wrappers around wrappers around wrappers etc...). > There is a way to find the length of a string parameter, though there > isn't a good library interface for it.  The security.jail.param.* > sysctls describe the form of the parameters, giving the type. The > "contents" of these sysctls  are generally unused (and set to zero), but > for string parameters there's actually the max length of the string > (itself in string form). Thanks, this works great for strings! > For non-string parameters, the length in > string form depends on the type of the parameters, so for an int you'll > need as long as the string representation of an ant can be, etc.  I > don't know how much good C code will do for you for Rust work, but you > might want to take a look at jailparam_type() in the libjail source code. > It gets more complicated with array parameters, those that can hold an > arbitrary number of values.  The IP addresses are the best example of > that. I've now hit that snag. I see that the security.jail.param.ip4.addr and security.jail.param.ip6.addr sysctls contain the sizes of an in_addr_t and an in6_addr_t, respectively. How would I now determine the number of IPv4 and IPv6 addresses, or should I just allocate security.jail.jail_max_af_ips per family? I've tried to go through how libjail does it, but don't quite understand it, nor the implied race conditions (?) it attempts to mitigate by reading the vector multiple times: lib/libjail/jail.c: /* * Get the prison. If there are array elements, retry a few times * in case their sizes changed from under us. */ for (sanity = 0;; sanity++) { [...] Fabian