Date: Mon, 03 Jun 2019 13:40:08 -0600 From: James Gritton <jamie@freebsd.org> To: jail@freebsd.org Subject: Re: svn commit: r348509 - head/lib/libjail Message-ID: <181db50621f67ffd6ed7ca8355454c91@freebsd.org> In-Reply-To: <CACNAnaET5zG%2B=do4Z1hN1cq-mj_BryAtScPjVbUFF__AtJd84w@mail.gmail.com> References: <201906021403.x52E3v0x067698@repo.freebsd.org> <CACNAnaET5zG%2B=do4Z1hN1cq-mj_BryAtScPjVbUFF__AtJd84w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <kevans@freebsd.org> 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 <stefan.hegnauer gmx ch> >> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?181db50621f67ffd6ed7ca8355454c91>