On 11/26/25 05:17, Zygmunt Krynicki wrote:
Hello
I'd like to propose splitting the textual permission "w", so that it does not imply
AA_MAY_DELETE if the file is a device, fifo or socket. Profiles routinely grant "w"
permission, but nobody in their right mind expects applications to delete such files.
this has been planned and is supported on the backend. We still need to fix the
frontend (long term todo that is coming)
The question is how to deal with it in policy, there are basically two ways,
introduce finer permission to policy that can be used along side the current.
Or stick it behind an abi flag. The abi flag seems like a cleaner solution to me
Both userspace and kernel can already kind-of express this. The only question
is how to do that in a way that doesn't force a painful profile transition. I
think we need a new permission bit.
we have that is the backend. An update to the front end, that moves the mapping
for old perms to the backend is coming, its something I very much would have
liked to have had landed already
My suggestion would be to add a AA_MAY_DELETE_SPECIAL permission. Starting with
some future ABI deleting devices, fifos and sockets would check
AA_MAY_DELETE_SPECIAL. Compatibility layer in the kernel would then continue to
grant AA_MAY_DELETE_SPECIAL for older ABIs.
Well the plan here was to actually expose fifo/socket/link/.. as a rule
conditional. Then you don't need a special MAY_DELETE, you just need delete,
and the correct conditional.
For compatibility we map the permissions, and the conditional is just defaulted
to all types.
On the userspace side we might define new syntax such as:
allow file PATH D,
Where D implies delete special.
I was thinking more of using
allow file type=file /foo delete,
allow file type!=char /foo delete,
I'm happy to take a stab at implementing it. The only thing I'm not sure is how to name
the new feature "delete_special".
I'm grateful for your thoughts
Best regards
ZK
