Once again, this time actually updating the diff...

As suggested by bz@, I've only removed the sysctls #ifdef BURN_BRIDGES.

I have another revision in the works, D14791, which removes those deprecated global permission parameters. Since this patch works with those parameters, I would naturally adjust whichever one goes in last (provided I get away with the parameter removal).

Te latest diff, to account for the changes I committed to neaten the somewhat messy pr_allow_names/pr_allow_nonames array pairs. And I also went with bumping VFS_VERSION instead of __FreeBSD_version.

In D14681#309678, @kib wrote:

I you might want to bump VFS_VERSION instead of __FreeBSD_version.

The latest changes:

• Put the bits back into pr_allow. Adding pr_allow_mount only served to duplicate code.
• Make the KBI change: put a prison flag in struct vfsconf.
• Replace prison_check_vfs with a call to prison_allow (another advantage of using pr_allow).
• Use asprintf in prison_add_vfs, instead of sprintf/strdup.
• Do the right thing ifdef NO_SYSCTL_DESCR.

I've updated the diff to:

In D14681#308570, @jhb wrote:

One more thought: if you use the value from 'vfc_name' as the pointer you set in the array, you don't have to do actual string comparisons but can just do pointer compares to find the matching index (and thus bit) in the array in prison_check_vfs(). The jail parameter logic would still have to do string compares though.

In D14681#308541, @jhb wrote:

For per-jail settings I would still be tempted to not try to reserve space in the names, but instead perhaps have a separate "allow" mask just for VFS, and parse mount parameters explicitly.

Yes, I could do that - there are a few unused spots in struct prison to make it easy. Then I could leave pr_allow_names pretty much alone (except removing the old static allow.mount.*).

In D14681#308495, @jhb wrote:

... You could just add a new 'VFCF_JAIL_ALLOW' which is a dynamic flag that the sysctl knobs turn on/off. The sysctl node would be a SYSCTL_PROC handler and it can take a pointer to the 'struct vfsconf' as its arg2 value.

In D14681#308495, @jhb wrote:

I'm not quite a fan of the manual sysctl tree walking. I also don't think you need to worry about pre-creating sysctls if they are written to. I think it is perfectly reasonable to only create the sysctl when the VFS module is loaded (and that's more typical). I think it is cleaner instead of allocating pr_allow bits on the fly, to instead use a flag in the 'struct vfsconf' to be the jail permission. You could just add a new 'VFCF_JAIL_ALLOW' which is a dynamic flag that the sysctl knobs turn on/off. The sysctl node would be a SYSCTL_PROC handler and it can take a pointer to the 'struct vfsconf' as its arg2 value. This avoids concerns about running out of bits, etc. For this you would want to change prison_check_vfs() to take a pointer to 'struct vfsconf' instead of the name.

I'm good with it - I was just waiting for suggested changed to make it in.

One more thing to make it complete: something in the jail(8) man page. There's a pseudo-parameters section for things that aren't part of the kernel interface, where this would belong.

Now that it's not really part of the exec system (aside from execing a program itself for convenience), exec.cpuset doesn't sound like the best name. I think cpuset.list would be good, or at least something under the cpuset.* umbrella since cpuset.id already exists.

It has only exhausted 16 bits, no? I would think if you added the flag but left pr_allow as plain "unsigned" your kernel would still work.

In D10770#223306, @swills wrote:

@jamie Does the updated patch look like what you had in mind?

In D10770#223220, @swills wrote:

Is it a bug in cr_canseeotheruids() and cr_canseeothergids() that they don't hide processes in jails that happen to be the same uid/gid (but aren't the same user because they're in a jail)?

In D10770#223200, @swills wrote:

Wait, I'm confused. If that's sufficient, then why am I seeing (as a non privileged user on the host) processes running in jails when I have security.bsd.see_other_gids and security.bsd.see_other_uids set to 0 (the processes happen to be the same UID as my user but aren't the same user)?

No, cr_seeotheruids() and c r_seeothergids() are fine as is. Since prison_check() comes before everything else, those don't need to worry about th prison situation. You still need the new sysctl though, for the originally identified reason.

prison_check() is required in all cases, because it covers jails that can never be seen, i.e. if you're trying to see processes in a parent jail, or a jail is trying to see the base system. The reason prison_check() does the equality test is because prison_ischild() checks for a "<" kind of relationship when we want a "<=" check.

jailed() isn't the right test. It handles someone on the host system looking at jailed users' processes, but doesn't handle the sub-jail case. If a user in p1 is looking at processes, he shouldn't see anything from p2 which is a jail under p1. Yet, both creds will show up as "jailed".

You don't need the KP_ALLOW_RESERVED_PORTS in jailp.h and config.c - you can just leave these files untouched. The KP_* defines are for parameters that are internally referenced somewhere within jail(8). That includes most of the allow.* parameters, only to handle back-compatibility with the security.jail.*_allowed sysctls.

Rather than the "jail does not exist" error message for a jid of -1, you can use jail_errmsg which is already set by jail_getid. See setifvnet() in ifconfig.c for an example. And while the second "jail does not exist" message for EINVAL is admirably complete, it seems a touch overkill for the race diction of a jail going away between the "-j" parsing and the jail_attach().

In D9649#203147, @mjg wrote:

I think the jail_attach interface is fundamentally unsuitable for this purpose. The problem is the process appears in the jail.

Instead, there should be a way to restrict your actions to ones only affecting the target jail while not entering it and alter back away from it after you are done. This could be accomplished by providing e.g. jail-based file descriptors. You obtain jail fds for jails you want to modify and for the jail you are in right now so that you can go back.

I was going to commit, but noticed one thing: the "{ql:ipv4_addr}" (or ipv6_addr) in emit_ip_addr_list's emit_str doesn't ever get reflected in the output (which I think it proper). Does it need to be there at all, or am I missing something? I admit to not being close to a libxo expert.

In D8766#183598, @me_cschwarz.com wrote:

Suggestion for a commit message. Is this too long?
...

emit_ip_addr() is always called surrounded by calls to xo_open_list and xo_close_list. It seems cleaner to have those calls as part of emit_ip_addr() istself. It would take an extra parameter of the name that xo_open and xo_close need, but then fewer lines of code overall.

I don't think the man page needs to change for this. While it's different than the output used to look, there's no more reason to note such specifics of the libxo output format there than there was before.

Sorry I got sidetracked by that bit, and that it was the only thing I had to say at the time - I just wasn't available to follow up today. Yeah, the actual substantial part of the change looks good.

Surely those blackslashes at the ends of the lines shouldn't be there?