On Thu, 20 Mar 2014 11:32:51 -0400 tytso@xxxxxxx wrote: > On Wed, Mar 19, 2014 at 08:06:45PM +0100, David Herrmann wrote: > > > > This series introduces the concept of "file sealing". Sealing a file restricts > > the set of allowed operations on the file in question. Multiple seals are > > defined and each seal will cause a different set of operations to return EPERM > > if it is set. The following seals are introduced: > > > > * SEAL_SHRINK: If set, the inode size cannot be reduced > > * SEAL_GROW: If set, the inode size cannot be increased > > * SEAL_WRITE: If set, the file content cannot be modified > > Looking at your patches, and what files you are modifying, you are > enforcing this in the low-level file system. > > Why not make sealing an attribute of the "struct file", and enforce it > at the VFS layer? That way all file system objects would have access > to sealing interface, and for memfd_shmem, you can't get another > struct file pointing at the object, the security properties would be > identical. Would it be more sensible to have a "sealer" which is a "device" which you give a file handle too and it gives you back a sealable one. So for the memfd case you'd create a private handle, pass it to the sealer, and then pass the sealer handles to everyone else. You have to implicitly trust the creator of the object has - handed you the object you expect - sealed it so that appears no weaker but means you can meaningfully created sealed versions of arbitary objects and if you want have non-sealed ones around with it being up to the creator if they want for example to simply close the unsealed one immediately afterwards. 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>