> 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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>