Hi On Thu, Mar 20, 2014 at 4:49 AM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > Is there really any use-case where the sealer isn't also the same > thing that *created* the file in the first place? Because I would be a > ton happier with the notion that you can only seal things that you > yourself created. At that point, the exclusive reference isn't such a > big deal any more, but more importantly, you can't play random > denial-of-service games on files that aren't really yours. 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 mandatory locking and noticed that it provides similar restrictions on _all_ files. Mandatory locks can be more easily removed, but an 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). But I understand that it is quite hard to review all the possible scenarios. So I'm fine with checking inode-ownership permissions for SET_SEALS. We could also make sealing a one-shot operation. Given that in a no-trust situation there is never a guarantee that the other side drops its references, re-using a sealed file is usually not possible. However, in sane environments, this could be a nice optimization in case the other side plays along. The one-shot semantics would allow dropping reference-checks entirely. The inode-ownership semantics would still require it. Thanks David -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
