Should this not do the same as 9134ed157388f3e34374322a5de06449a031f1ec?

@adrian could you perhaps look into getting this reviewed and committed upstream?

Note that @grembo , while AFK, indicated his approval to me over email.

In D46284#1299021, @crest_freebsd_rlwinm.de wrote:

In D46284#1298773, @kevans wrote:

I had hoped to attend the jail user call today to be able to discuss this, but the Discord event has it an hour off and I didn't discover the authoritative source @ callfortesting.org until I was wondering why nobody was showing up. *deep sigh*

I don't think we're comfortable, as a project, to enable this for all users of jail(8) by default without an additional flag. I appreciate that you want to do stuff like this with existing jail scripts but this is a huge POLA violation (even assuming proper communication across a major branch update) with security implications, and I don't think enabling maybe-executable config scripts is a pattern that we really want propagating.

There was some discussion out-of-band after a concerned user reached out about this, and it was pointed out to me that automountd does the same thing, so I've pitched a review to try and neuter that a bit because that's terrifying: D56680.

The jail.conf(5) format already defines hooks that by design execute as root on the host (exec.prepare/created/prestart/poststart/prestop/poststop/release). Having any untrusted jail.conf(5) on the system is a game over scenario similar to having a malicous /etc/crontab or rc.d script installed. Moving the attack surface a few milliseconds forward from the exec.prepare (or exec.prestop when removing a jail) stage to the config parsing stage doesn't increase the attack surface in a meaningful way.

LGTM, please see my comment.

In D56691#1298953, @sarah.walker2_arm.com wrote:

In D56691#1298952, @zlei wrote:

How can alignment lead locking issues ? Not an expert on this, just out of curious.

The standard behaviour for busdma_bounce implementations is that bus_dmamap with alignment > 1 is marked as COULD_BOUNCE. Among other things this can cause a bounce zone to be allocated at bus_dmamap creation time. This causes further allocations without M_NOWAIT which triggers the locking issue.

In D46284#1299031, @imp wrote:

In D46284#1299021, @crest_freebsd_rlwinm.de wrote:

@kevans: Can you think of a realistic situation where someone will have their jail configuration unintentionally executable? I don't think chmod -R 777 /etc is a supported configuration. Are we forced to support FAT32 as root file system on any strange platform or something like that?

That's the wrong question. For security related things, you have to default to 'fail safe' and this feature fails to meet that criteria.

In D46284#1299021, @crest_freebsd_rlwinm.de wrote:

@kevans: Can you think of a realistic situation where someone will have their jail configuration unintentionally executable? I don't think chmod -R 777 /etc is a supported configuration. Are we forced to support FAT32 as root file system on any strange platform or something like that?

Update comment