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 <kev...@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-unsubscr...@freebsd.org"
