svn commit: r348509 - head/lib/libjail
James Gritton
jamie at freebsd.org
Mon Jun 3 19:49:17 UTC 2019
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 at 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
More information about the freebsd-jail
mailing list