[apparmor] Splitting unlink from write

[John Johansen]

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
>