[prev in list] [next in list] [prev in thread] [next in thread]
List: freebsd-jail
Subject: Re: svn commit: r348509 - head/lib/libjail
From: James Gritton <jamie () freebsd ! org>
Date: 2019-06-03 19:40:08
Message-ID: 181db50621f67ffd6ed7ca8355454c91 () freebsd ! org
[Download RAW message or body]
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
_______________________________________________
freebsd-jail@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic