libgeom: Open the control device read-write
AcceptedPublic
Actions

Authored by des on Fri, Sep 11, 2:51 PM.

Details

Reviewers

kevans
markj
phk
mav
glebius
imp
emaste

Group Reviewers

geom

Summary

Try to open the control device read-write first, and fall back to
read-only if that fails and the error is EACCES.

MFC after: 1 week
Event: EuroBSDCon 2026 DevSummit

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Skipped

Unit

Tests Skipped

Build Status

Buildable 76777
Build 73660: arc lint + arc unit

Event Timeline

des created this revision.Fri, Sep 11, 2:51 PM

Herald added a subscriber: imp. · View Herald TranscriptFri, Sep 11, 2:51 PM

des requested review of this revision.Fri, Sep 11, 2:51 PM

Harbormaster completed remote builds in B76777: Diff 186468.Fri, Sep 11, 2:51 PM

des added a parent revision: D59591: geom: Check file flags before handling control request.Fri, Sep 11, 2:51 PM

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.

This revision is now accepted and ready to land.Fri, Sep 11, 4:36 PM

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?

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.

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.