Re: svn commit: r348509 - head/lib/libjail

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r348509 - head/lib/libjail

Kyle Evans-3
(Resend to get the list address right- sorry Jamie!)

On Sun, Jun 2, 2019 at 9:04 AM Kyle Evans <[hidden email]> 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.

Thanks,

Kyle Evans
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r348509 - head/lib/libjail

James Gritton-2
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 <[hidden email]> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "[hidden email]"