My first idea was to add MFD_ALLOW_SEALING as memfd_create() flag, which enables the sealing-API for that file. Then I looked at POSIX
This actually seems the most sensible to me. The reason being that if I have some existing used object there is no way on earth I can be sure who has existing references to it, and we don't have revoke() to fix that.
So it pretty much has to be a new object in a sane programming model.
mandatory locking and noticed that it provides similar restrictions on _all_ files. Mandatory locks can be more easily removed, but an
The fact someone got it past a standards body doesn't make it a good idea.
attacker could just re-apply them in a loop, so that's not really an argument. Furthermore, sealing requires _write_ access so I wonder what kind of DoS attacks are possible with sealing that are not already possible with write access? And sealing is only possible if no writable, shared mapping exists. So even if an attacker seals a file, all that happens is EPERM, not SIGBUS (still a possible denial-of-service scenario).
I think you want two things at minimum
owner to seal root can always override
I would query the name too. Right now your assumption is 'shmem only' but that might change with other future use cases or types (eg some driver file handles) so SHMEM_ in the fcntl might become misleading.
Whether you want some way to undo a seal without an exclusive reference as the file owner is another question.
Alan