From mboxrd@z Thu Jan 1 00:00:00 1970 From: One Thousand Gnomes Subject: Re: [PATCH 0/6] File Sealing & memfd_create() Date: Thu, 20 Mar 2014 14:41:27 +0000 Message-ID: <20140320144127.1d411f26@alan.etchedpixels.co.uk> References: <1395256011-2423-1-git-send-email-dh.herrmann@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Linus Torvalds , Linux Kernel Mailing List , Hugh Dickins , Alexander Viro , Karol Lewandowski , Kay Sievers , Daniel Mack , Lennart Poettering , Kristian =?UTF-8?B?SMO4Z3NiZXJn?= , John Stultz , Greg Kroah-Hartman , Tejun Heo , Johannes Weiner , DRI , linux-fsdevel , linux-mm , Andrew Morton , Ryan Lortie , "Michael Kerrisk (man-pages)" Return-path: In-Reply-To: Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org > 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@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org