libgeom: Open the control device read-write

[des]

Summary

Try to open the control device read-write first, and fall back to
read-only if that fails and the error is EACCES. This prepares us for a
future in which GEOM requires write access to execute verbs that modify
the configuration.

MFC after: 1 week
Event: EuroBSDCon 2026 DevSummit

[imp]

The only concern I have with the kernel enforcing write is what happens if we boot old binary, new kernel (which is quite typical). Would we have situations where we can't configure the system enough to build/install a new binary.

[des]

In D59592#1367478, @imp wrote:

The only concern I have with the kernel enforcing write is what happens if we boot old binary, new kernel (which is quite typical). Would we have situations where we can't configure the system enough to build/install a new binary.

We could add some logic in g_ctl_ioctl() that sets FWRITE if the caller is the superuser, and then remove it in a year or two? Or make it conditional on COMPAT_FREEBSD15?

[kevans]

In D59592#1367544, @des wrote:

In D59592#1367478, @imp wrote:

The only concern I have with the kernel enforcing write is what happens if we boot old binary, new kernel (which is quite typical). Would we have situations where we can't configure the system enough to build/install a new binary.

We could add some logic in g_ctl_ioctl() that sets FWRITE if the caller is the superuser, and then remove it in a year or two? Or make it conditional on COMPAT_FREEBSD15?

I like the idea of hiding it behind COMPAT_FREEBSD15 with the intention of ripping it out in a year or two We could also maybe haggle over a security.* sysctl to allow the new behavior now, so that one can get it early without having to compromise on compat to improve their security posture when they otherwise wouldn't.

[des]

In D59592#1367584, @kevans wrote:

In D59592#1367544, @des wrote:

In D59592#1367478, @imp wrote:

The only concern I have with the kernel enforcing write is what happens if we boot old binary, new kernel (which is quite typical). Would we have situations where we can't configure the system enough to build/install a new binary.

We could add some logic in g_ctl_ioctl() that sets FWRITE if the caller is the superuser, and then remove it in a year or two? Or make it conditional on COMPAT_FREEBSD15?

I like the idea of hiding it behind COMPAT_FREEBSD15 with the intention of ripping it out in a year or two We could also maybe haggle over a security.* sysctl to allow the new behavior now, so that one can get it early without having to compromise on compat to improve their security posture when they otherwise wouldn't.

See D59591

[markj]

The commit log explains what the change is doing, but not why it's doing it. (I know the reason, but it should still be explained.)