From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) by kanga.kvack.org (Postfix) with ESMTP id 9760F6B0035 for ; Thu, 10 Apr 2014 19:16:03 -0400 (EDT) Received: by mail-ig0-f181.google.com with SMTP id h18so123961igc.14 for ; Thu, 10 Apr 2014 16:16:03 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [2607:f8b0:4001:c03::22a]) by mx.google.com with ESMTPS id ac8si5140913icc.0.2014.04.10.16.16.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Apr 2014 16:16:02 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id rd18so4698168iec.1 for ; Thu, 10 Apr 2014 16:16:01 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: 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> Date: Fri, 11 Apr 2014 01:16:00 +0200 Message-ID: Subject: Re: [PATCH 0/6] File Sealing & memfd_create() From: David Herrmann Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Andy Lutomirski Cc: Theodore Ts'o , linux-kernel , Kay Sievers , Daniel Mack , Lennart Poettering , John Stultz , Greg Kroah-Hartman , "dri-devel@lists.freedesktop.org" , linux-fsdevel , linux-mm , Andrew Morton , Linus Torvalds , Ryan Lortie , "Michael Kerrisk (man-pages)" Hi On Fri, Apr 11, 2014 at 1:05 AM, Andy Lutomirski wrote: > /proc/pid/fd is a really weird corner case in which the mode of an > inode that doesn't have a name matters. I suspect that almost no one > will ever want to open one of these things out of /proc/self/fd, and > those who do should be made to think about it. I'm arguing in the context of memfd, and there's no security leak if people get access to the underlying inode (at least I'm not aware of any). As I said, context information is attached to the inode, not file context, so I'm fine if people want to open multiple file contexts via /proc. If someone wants to forbid open(), I want to hear _why_. I assume the memfd object has uid==uid-of-creator and mode==(777 & ~umask) (which usually results in X00, so no access for non-owners). I cannot see how /proc is a security issue here. Thanks David -- 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