From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yk0-f173.google.com (mail-yk0-f173.google.com [209.85.160.173]) by kanga.kvack.org (Postfix) with ESMTP id 2579A6B024D for ; Thu, 20 Mar 2014 12:38:19 -0400 (EDT) Received: by mail-yk0-f173.google.com with SMTP id 10so2915178ykt.4 for ; Thu, 20 Mar 2014 09:38:18 -0700 (PDT) Received: from imap.thunk.org (imap.thunk.org. [2600:3c02::f03c:91ff:fe96:be03]) by mx.google.com with ESMTPS id h55si2730812yhi.102.2014.03.20.09.38.17 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 20 Mar 2014 09:38:17 -0700 (PDT) Date: Thu, 20 Mar 2014 12:38:06 -0400 From: tytso@mit.edu Subject: Re: [PATCH 0/6] File Sealing & memfd_create() Message-ID: <20140320163806.GA10440@thunk.org> References: <1395256011-2423-1-git-send-email-dh.herrmann@gmail.com> <20140320153250.GC20618@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: David Herrmann Cc: linux-kernel , Hugh Dickins , Alexander Viro , Karol Lewandowski , Kay Sievers , Daniel Mack , Lennart Poettering , John Stultz , Greg Kroah-Hartman , Tejun Heo , Johannes Weiner , "dri-devel@lists.freedesktop.org" , linux-fsdevel , linux-mm , Andrew Morton , Linus Torvalds , Ryan Lortie , "Michael Kerrisk (man-pages)" On Thu, Mar 20, 2014 at 04:48:30PM +0100, David Herrmann wrote: > On Thu, Mar 20, 2014 at 4:32 PM, wrote: > > 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. > > Sealing as introduced here is an inode-attribute, not "struct file". > This is intentional. For instance, a gfx-client can get a read-only FD > via /proc/self/fd/ and pass it to the compositor so it can never > overwrite the contents (unless the compositor has write-access to the > inode itself, in which case it can just re-open it read-write). Hmm, good point. I had forgotten about the /proc/self/fd hole. Hmm... what if we have a SEAL_PROC which forces the permissions of /proc/self/fd to be 000? So if it is a property of the attribute, SEAL_WRITE and SEAL_GROW is basically equivalent to using chattr to set the immutable and append-only attribute, except for the "you can't undo the seal unless you have exclusive access to the inode" magic. That does make it pretty memfd_create specific and not a very general API, which is a little unfortunate; hence why I'm trying to explore ways of making a bit more generic and hopefully useful for more use cases. Cheers, - Ted -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org