In D53954#1239739, @olce wrote:

In D53954#1239729, @kevans wrote:

I'm not sure I understand this last bit

Oh... It's just a pilot error on my part, sorry!

I'm already passing the struct vfsoptlist all around so that MAC modules can reject jail_[sg]et operations based on the parameters they want to fetch or set.

Don't know how I managed to forget that for a while.

I just wanted to limit propagation of struct vfsoptlist elsewhere, but passing it makes sense for some hooks, so nevermind.

In D53954#1239691, @olce wrote:

In D53954#1239668, @kevans wrote:

I'm not too worried about that, though it does occur to me that it probably makes sense to stop setting an error in the opts for any of those checks. The MAC policy should probably have free reign over both errno and error probably in case it's some kind of custom vendor integration.

I agree, we should probably stop setting the err opt. But that doesn't solve the discoverability of whether MAC (and not, e.g., real nonexistence of a jail) was the reason some access was denied, as in non-MAC we still set "errmsg" in the VFS options.

Giving this control to MAC modules would be nice; that requires obviously changing the interface of the hooks (if you do it, please don't pass struct vfsoptlist all around, but instead some function pointer to a printf-like function, so that we can clean up the use of struct vfsoptlist in jails at some point).

In D53954#1239654, @olce wrote:

Coming back to highlights, there's indeed still the problem that enumeration returns an error if the last jail is denied via mac_prison_check_get(), so doing what you suggest is probably mandatory: Put back the MAC check in the loop, and once a jail is returned, jump to a prison_found_nomac label, even a _nomac_noalive variant as to eliminate also the (harmless) redundant test.

Additionally, as mentioned before, there's that, if mac_prison_check_get() denies access, we return a VFS error saying "access denied by MAC" which would be an info leak for situations where the jail must remain hidden. E.g., we could have mac_prison_check_get() return EPERM for a visible deny and ENOENT for an invisible one, and then treat them differently with respect to vfs_opterror(). But it seems that goes farther than what you're envisioning at this point (I haven't checked further revisions in the series thoroughly yet, to see if they need something like this).

Ping

Ping; any other complaints besides the type nits? I'll fix those to use standard types for the next revision or pre commit.

Highlights:

• Reorganize mac_get_prison() to reduce failure modes and drop the prison lock on the way out
• Assert that the lock is in the correct state afterwards in kern_jail_get()

Highlights:

• Removed prison_check_list, because it's of limited value; this could pose a problem if check_get rejects a prison as lastjid enumeration would halt when MAC denied it, but that probably requires a different solution
• Moved mac_prison_check_get calls to after found_prison, but on the tail of that last note, it might make sense to provide a found_prison_nomac and move one check back into the lastjid loop and just continue if we encounter one that we can't fetch. This would be cleaner than policies having to implement both a check_list and check_get to avoid breaking enumeration
• Moved the attach check to the point that we're about to attach; there are other ways this can fail from external modules anyways (e.g., osd), so trying to keep it all atomic may not be worth as much as being sure that the policy can examine the current properties of the jail. This also ensures that the creation+attach case is covered
• Add missing unlocking

Highlights:

• Remove mac_prison_create_init(): one would probably want to special-case prison0 earlier in mac_prison_init(), and they don't actually need to know anything about prison0 specifically: pr_parent == NULL is a good indicator of the root prison
• Don't leak labels, call mac_prison_destroy()
• Drop a bunch of locking assertions in label operations

In D53814#1233992, @quentin.thebault_defenso.fr wrote:

Added a unix: prefix for UNIX domain sockets

This enables the use of relative paths.
To avoid parsing the configuration value twice, I decided to pass a sa_family_t parameter to the rfb_init function. I hope that is an acceptable way to implement it.

Implementation looks fine to me, but I defer to bhyve-y folks for final review... in particular, I do wonder if they might prefer some more explicit prefix like unix:/path/to/sock

Just dropping a note that this leads to ~10x throughput to pkg.f.o on my laptop -- previously averaging somewhere around ~2-3mbit/s due to constant out-of-order acks, up to ~25-30 mbit/s on average

In D53750#1227230, @jlduran wrote:

I suggested via email:

diff
--- a/usr.bin/lam/lam.c
+++ b/usr.bin/lam/lam.c
@@ -213,11 +213,11 @@ gatherline(struct openfile *ip)
        *p = '\0';
        if (c == EOF) {
                ip->eof = 1;
+               if (ip->fp == stdin)
+                       fclose(stdin);
                if (ferror(ip->fp)) {
                        err(EX_IOERR, NULL);
                }
-               if (ip->fp == stdin)
-                       fclose(stdin);
                morefiles--;
                return (pad(ip));
        }

But this is fine as well. Plus, it has tests!

Hmm, the definition came in here:

-1 -> 0

Add missing size check to the startmethod _attach()

I know ray@ pops in sometimes so we might give him (and Ed) a little time to object, but I also didn't really see a reason to impose this particular limit. I did wonder if it was just an oversight because NSIG on other platforms *does* usually cover all valid signals (as far as I've observed)

Describe the switch a little more in HISTORY and update the STANDARDS; the
notable changes since -2004 are this different error return and clarification
of EFBIG to surface if the file size limit is exceeded (with generation of a
SIGXFSZ).

Do a read-once load of si_drv1, just in case. Amend the comment to try and
describe our solution more completely

Correct it for the file-specific unsupported mode as well

Fix observed test failures; there's only a few places that we expect EINVAL.

Simplify a bit using the net epoch

In D52740#1221574, @0mp wrote:

In D52740#1221525, @ziaee wrote:

(not a inetd-sme) I thought they were Nm because these utilities are part of inetd?

AFAIU, these utilities are just called by inetd and are not internal. I've not checked the code but my understanding is that inetd is able to run any service the user specifies in the config file.

Dance around tunmtx to protect against concurrent tun_destroy() / tunopen()

Already landed in a505b80b2f038409300cd05e2ea95822942404e2, and it's clear nobody is using it in a way that this is urgent to MFC independently