On Thu, Apr 10, 2014 at 4:16 PM, David Herrmann dh.herrmann@gmail.com wrote:
Hi
On Fri, Apr 11, 2014 at 1:05 AM, Andy Lutomirski luto@amacapital.net 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).
I'm not sure what you mean.
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.
On further reflection, my argument for 000 is crap. As far as I can see, the only time that the mode matters at all when playing with /proc/pid/fd, and they only way to get a non-O_RDWR memfd is using /proc/pid/fd, so I'll argue for 0600 instead.
Argument why 0600 is better than 0600 & ~umask: either callers don't care because the inode mode simply doesn't matter or they're using /proc/pid/fd to *reduce* permissions, in which case they'd probably like to avoid having to play with umask or call fchmod.
Argument why 0600 is better than 0777 & ~umask: People /prod/pid/fd are the only ones who care, in which case they probably prefer for the permissions not be increased by other users if they give them a reduced-permission fd.
Anyway, this is all mostly unimportant. Some text in the man page is probably sufficient, but I still think that 0600 is trivial to implement and a little bit more friendly.
--Andy
Thanks David