diff options
| author | Christian Brauner <brauner@kernel.org> | 2026-07-10 11:33:25 +0200 |
|---|---|---|
| committer | Christian Brauner <brauner@kernel.org> | 2026-08-03 10:08:39 +0200 |
| commit | 22c879a60d8248f9941e03145edea7cbd44ad864 (patch) | |
| tree | daa6237178cc25cae8b940e312d9465fc95f5780 /tools/unittests/git@git.tavy.me:linux.git | |
| parent | 3ca485a067c650ca8d6d146faae41d130d7324aa (diff) | |
binfmt_misc: allow removing entries via unlink(2)
Removing a binary type handler requires echoing -1 into its entry
file which works but is an odd interface to discover for something
that already looks like a plain file in a filesystem. The comment on
remove_binfmt_handler() has been suggesting a proper ->unlink()
method for years, so add one: unlinking an entry file unhashes the
entry from the handler list and removes the file, exactly like
writing -1 to it does. The status and register control files refuse
removal with EPERM the same way binderfs protects binder-control.
Writing -1 keeps working.
Permission-wise nothing new is exposed: unlink(2) requires write
access to the root directory which is owned by the (user namespace)
root with mode 0755, matching the privilege needed to write to the
0644 entry files. The VFS calls ->unlink() with the root inode lock
held so the existing writer serialization scheme applies unchanged,
and eviction of the unlinked inode drops the entry reference exactly
as for the write based removal.
Document the new way in admin-guide/binfmt-misc.rst.
Link: https://patch.msgid.link/20260710-work-binfmt_misc-locking-v3-24-a162f7cb58d6@kernel.org
Reviewed-by: Jori Koolstra <jkoolstra@xs4all.nl>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Diffstat (limited to 'tools/unittests/git@git.tavy.me:linux.git')
0 files changed, 0 insertions, 0 deletions
