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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
