Page MenuHomeFreeBSD

jail(8): make '-cm' run 'command=' in modify case as well
AbandonedPublic

Authored by igoro on Nov 19 2023, 1:15 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Nov 12, 11:25 PM
Unknown Object (File)
Tue, Nov 12, 8:56 PM
Unknown Object (File)
Oct 4 2024, 7:39 PM
Unknown Object (File)
Oct 4 2024, 1:49 PM
Unknown Object (File)
Oct 1 2024, 5:36 PM
Unknown Object (File)
Sep 29 2024, 2:27 AM
Unknown Object (File)
Sep 28 2024, 3:39 PM
Unknown Object (File)
Sep 25 2024, 3:37 AM
Subscribers

Details

Reviewers
None
Group Reviewers
Jails
Summary

It allows to get command= be applied in case the given jail exists and -cm means modification instead of creation. It also handles a case when nopersist command= is used, i.e. the command runs first and nopersist takes place after, what removes the jail after the command, not before.

I think it could be found useful in some scripting and other simple cases when it needs no additional if/else logic, e.g. it could be a sequence of invocations with the same set of jail params, but different commands, and when we know that this is the last command and a jail should be revoked we could simply add nopersist to the params:

  • jail -cm <the-same-params-with-persist> command=one
  • jail -cm <the-same-params-with-persist> command=two
  • jail -cm <the-same-params-with-persist> nopersist command=last

Initially this patch was created while I was working on the cheapest variant of kyua jail support, but it ended up with another, more explicit, approach.

As long as some time was invested I would like to share this prototype, in case it's found interesting. But I completely understand that it can be a definite "no-no" due to established behavior and philosophy.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

igoro requested review of this revision.Nov 19 2023, 1:15 PM

The command parameters (including "command" itself) are well established as being run during jail setup and teardown. I would expect a lot of existing configuration to have problems with the command being run when the jail has already started up. While it makes sense on the command line, I don't want to break the connection between file configuration and command line configuration (more than it's already broken).

This could be fixed with perhaps an option to direct scripts to be run on modification. Or perhaps yet another exec.foo parameter, since it's kind of arbitrary which scripts are run in the modify case (in particular, I noticed that exec.poststart isn't in the list).

Fair enough. Thank you. It was an expected outcome, it confirms my doubts. And I personally do not have production needs or something else to continue work on this and discuss possible alternatives or workarounds like exec.foo.

Thanks for your time and attention.