From owner-freebsd-jail@freebsd.org Mon Jun 3 19:49:17 2019 Return-Path: Delivered-To: freebsd-jail@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 5B1B915BC04C for ; Mon, 3 Jun 2019 19:49:17 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E9CD66C3AD for ; Mon, 3 Jun 2019 19:49:16 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id A732F15BC04B; Mon, 3 Jun 2019 19:49:16 +0000 (UTC) Delivered-To: jail@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 850A615BC04A for ; Mon, 3 Jun 2019 19:49:16 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from gritton.org (gritton.org [199.192.165.131]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 27B866C3AB; Mon, 3 Jun 2019 19:49:15 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from gritton.org ([127.0.0.131]) by gritton.org (8.15.2/8.15.2) with ESMTP id x53Je8Su036173; Mon, 3 Jun 2019 13:40:08 -0600 (MDT) (envelope-from jamie@freebsd.org) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 03 Jun 2019 13:40:08 -0600 From: James Gritton To: jail@freebsd.org Subject: Re: svn commit: r348509 - head/lib/libjail In-Reply-To: References: <201906021403.x52E3v0x067698@repo.freebsd.org> Message-ID: <181db50621f67ffd6ed7ca8355454c91@freebsd.org> X-Sender: jamie@freebsd.org User-Agent: Roundcube Webmail/1.3.8 X-Greylist: inspected by milter-greylist-4.6.2 (gritton.org [127.0.0.131]); Mon, 03 Jun 2019 13:40:08 -0600 (MDT) for IP:'127.0.0.131' DOMAIN:'[127.0.0.131]' HELO:'gritton.org' FROM:'jamie@freebsd.org' RCPT:'' X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (gritton.org [127.0.0.131]); Mon, 03 Jun 2019 13:40:08 -0600 (MDT) X-Rspamd-Queue-Id: 27B866C3AB X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.94 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.94)[-0.940,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2019 19:49:17 -0000 On 2019-06-03 13:33, Kyle Evans wrote: > (Resend to get the list address right- sorry Jamie!) > > On Sun, Jun 2, 2019 at 9:04 AM Kyle Evans wrote: >> >> Author: kevans >> Date: Sun Jun 2 14:03:56 2019 >> New Revision: 348509 >> URL: https://svnweb.freebsd.org/changeset/base/348509 >> >> Log: >> jail_getid(3): add special-case immediate return for jid 0 >> >> As depicted in the comment: jid 0 always exists, but the lookup will >> fail as >> it does not appear in the kernel's alljails list being a special >> jail. Some >> callers will expect/rely on this, and we have no reason to lie >> because it >> does always exist. >> >> Reported by: Stefan Hegnauer >> MFC after: soon (regression, breaks inspecting jail host bits, >> partial >> revert) >> >> Modified: >> head/lib/libjail/jail_getid.c >> >> Modified: head/lib/libjail/jail_getid.c >> ============================================================================== >> --- head/lib/libjail/jail_getid.c Sun Jun 2 09:28:50 2019 >> (r348508) >> +++ head/lib/libjail/jail_getid.c Sun Jun 2 14:03:56 2019 >> (r348509) >> @@ -54,6 +54,15 @@ jail_getid(const char *name) >> >> jid = strtoul(name, &ep, 10); >> if (*name && !*ep) { >> + /* >> + * jid == 0 is a special case; it will not appear in >> the >> + * kernel's jail list, but naturally processes will be >> assigned >> + * to it because it is prison 0. Trivially return >> this one >> + * without a trip to the kernel, because it always >> exists but >> + * the lookup won't succeed. >> + */ >> + if (jid == 0) >> + return jid; >> jiov[0].iov_base = __DECONST(char *, "jid"); >> jiov[0].iov_len = sizeof("jid"); >> jiov[1].iov_base = &jid; >> > > On a related note- do we have a good reason for not exposing jid 0 via > jail_get(2) if that's what's requested and we're operating in prison0? > I have no historical context here, so it's not clear to me what issues > that might expose other than the issue of exposing a prison that's not > all that interesting. There had been pushback on exposing the current prison via jid=0 when not in prison0, but I don't think the question was even considered for prison0. Not only is it not very interesting, it's largely blank. There are a few things like hostname that actually live in struct prison, but mostly it's a matter of limitations that don't apply to prison0. I actually like the idea of exposing the current prison with prison0, limiting jail_get(2) to excise outside information (like the path) but still report limits that a user may be interested in knowing and aren't a security concern to discover (and indeed, can often be found through more cumbersome means). - Jamie