From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756645AbaDVOSn (ORCPT ); Tue, 22 Apr 2014 10:18:43 -0400 Received: from mail-ie0-f169.google.com ([209.85.223.169]:36268 "EHLO mail-ie0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756550AbaDVOR5 (ORCPT ); Tue, 22 Apr 2014 10:17:57 -0400 MIME-Version: 1.0 In-Reply-To: References: <430cfc67aae9b9ad5eab4d293107285ad44c5fd9.1398097304.git.luto@amacapital.net> Date: Tue, 22 Apr 2014 16:17:57 +0200 Message-ID: Subject: Re: [RFC 2/2] fs,proc: Respect FMODE_WRITE when opening /proc/pid/fd/N From: David Herrmann To: Andy Lutomirski Cc: Pavel Machek , linux-kernel , linux-fsdevel , Alexander Viro , "Theodore Ts'o" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi On Tue, Apr 22, 2014 at 3:49 PM, Andy Lutomirski wrote: > Anyone who opens a file read-only and sends it over SCM_RIGHTS is > likely broken. They may think that it's read-only, so it can't be > written, but this /proc/fd issue means that whoever receives it can > reopen it. > > It's true that, if the inode doesn't allow the recipient write access, > then the recipient can't reopen, but there are lots of cases where the > inode can't reliably be expected not to allow write. For example, the > inode could be unlinked, an O_TMPFILE file, a memfd handle, or in a > non-world-executable directory, and the file mode should be respected. I think it's safe to assume that any object you create is never world-accessible. So the worst you can get is 0600. So if we now take your example, your patch doesn't fix the problem at all. Imagine two processes, $sender and $receiver. If the receiver runs as a different user as the sender, it cannot open /proc/self/fd/ writable due to 0600. So the only problematic case is if both run as the same user. However, in that case, the receiver can _always_ access /proc/$sender/fd/ and thus still gain writable access to the object, even if its own fd is read-only and your patch was applied. (ignoring the fact that they can kill() and ptrace each other..) Protecting world-accessible objects by hiding them is imho wrong. And protecting users against themselves is even worse. >> >> fd = open("/run", O_RDWR | O_TMPFILE); > > Did you mean fd = open("/run", O_RDWR | O_TMPFILE, 0666)? 0600? Sorry, I meant S_IWUSR | S_IRUSR (0600). Thanks David