svn commit: r348509 - head/lib/libjail

[James Gritton]

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