From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joel Fernandes Subject: Re: [PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd Date: Fri, 9 Nov 2018 17:49:13 -0800 Message-ID: <20181110014913.GA202500@google.com> References: <20181108041537.39694-1-joel@joelfernandes.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Michael Tirado Cc: Andy Lutomirski , Jann Horn , LKML , jreck@google.com, john.stultz@linaro.org, tkjos@google.com, gregkh@linuxfoundation.org, hch@infradead.org, viro@zeniv.linux.org.uk, Andrew Morton , dancol@google.com, bfields@fieldses.org, jlayton@kernel.org, khalid.aziz@oracle.com, Lei.Yang@windriver.com, linux-fsdevel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, marcandre.lureau@redhat.com, mike.kravetz@oracle.com, minchan@kernel.org, shuah@kernel.org, valdis.kletnieks@vt.edu, hughd@google.com, linux-api@vger.kernel.org List-Id: linux-api@vger.kernel.org On Fri, Nov 09, 2018 at 08:02:14PM +0000, Michael Tirado wrote: [...] > > > That aside: I wonder whether a better API would be something that > > > allows you to create a new readonly file descriptor, instead of > > > fiddling with the writability of an existing fd. > > > > Every now and then I try to write a patch to prevent using proc to reopen > > a file with greater permission than the original open. > > > > I like your idea to have a clean way to reopen a a memfd with reduced > > permissions. But I would make it a syscall instead and maybe make it only > > work for memfd at first. And the proc issue would need to be fixed, too. > > IMO the best solution would handle the issue at memfd creation time by > removing the race condition. I agree, this is another idea I'm exploring. We could add a new .open callback to shmem_file_operations and check for seals there. thanks, - Joel From mboxrd@z Thu Jan 1 00:00:00 1970 From: joel at joelfernandes.org (Joel Fernandes) Date: Fri, 9 Nov 2018 17:49:13 -0800 Subject: [PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd In-Reply-To: References: <20181108041537.39694-1-joel@joelfernandes.org> Message-ID: <20181110014913.GA202500@google.com> On Fri, Nov 09, 2018 at 08:02:14PM +0000, Michael Tirado wrote: [...] > > > That aside: I wonder whether a better API would be something that > > > allows you to create a new readonly file descriptor, instead of > > > fiddling with the writability of an existing fd. > > > > Every now and then I try to write a patch to prevent using proc to reopen > > a file with greater permission than the original open. > > > > I like your idea to have a clean way to reopen a a memfd with reduced > > permissions. But I would make it a syscall instead and maybe make it only > > work for memfd at first. And the proc issue would need to be fixed, too. > > IMO the best solution would handle the issue at memfd creation time by > removing the race condition. I agree, this is another idea I'm exploring. We could add a new .open callback to shmem_file_operations and check for seals there. thanks, - Joel From mboxrd@z Thu Jan 1 00:00:00 1970 From: joel@joelfernandes.org (Joel Fernandes) Date: Fri, 9 Nov 2018 17:49:13 -0800 Subject: [PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd In-Reply-To: References: <20181108041537.39694-1-joel@joelfernandes.org> Message-ID: <20181110014913.GA202500@google.com> Content-Type: text/plain; charset="UTF-8" Message-ID: <20181110014913.-GM4sbLpnCn5dBOZvQmWtL9v7T9EmQFvqWKwhpSuOh0@z> On Fri, Nov 09, 2018@08:02:14PM +0000, Michael Tirado wrote: [...] > > > That aside: I wonder whether a better API would be something that > > > allows you to create a new readonly file descriptor, instead of > > > fiddling with the writability of an existing fd. > > > > Every now and then I try to write a patch to prevent using proc to reopen > > a file with greater permission than the original open. > > > > I like your idea to have a clean way to reopen a a memfd with reduced > > permissions. But I would make it a syscall instead and maybe make it only > > work for memfd at first. And the proc issue would need to be fixed, too. > > IMO the best solution would handle the issue at memfd creation time by > removing the race condition. I agree, this is another idea I'm exploring. We could add a new .open callback to shmem_file_operations and check for seals there. thanks, - Joel