From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Weimer Subject: Re: [PATCH 0/6] File Sealing & memfd_create() Date: Tue, 17 Jun 2014 11:48:11 +0200 Message-ID: <53A00EDB.3050108@redhat.com> References: <1395256011-2423-1-git-send-email-dh.herrmann@gmail.com> <20140320153250.GC20618@thunk.org> <20140320163806.GA10440@thunk.org> <5346ED93.9040500@amacapital.net> <20140410203246.GB31614@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To: Andy Lutomirski , "Theodore Ts'o" , David Herrmann , 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 Lo Return-path: In-Reply-To: Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org On 04/10/2014 10:37 PM, Andy Lutomirski wrote: > It occurs to me that, before going nuts with these kinds of flags, it > may pay to just try to fix the /proc/self/fd issue for real -- we > could just make open("/proc/self/fd/3", O_RDWR) fail if fd 3 is > read-only. That may be enough for the file sealing thing. Increasing privilege on O_PATH descriptors via access through /proc/self/fd is part of the userspace API. The same thing might be true for O_RDONLY descriptors, but it's a bit less likely that there are any users out there. In any case, I'm not sure it makes sense to plug the O_RDONLY hole while leaving the O_PATH hole open. -- Florian Weimer / Red Hat Product Security Team -- 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