On Thu, Apr 10, 2014 at 1:49 PM, David Herrmann dh.herrmann@gmail.com wrote:
Hi
On Thu, Apr 10, 2014 at 10:37 PM, Andy Lutomirski luto@amacapital.net 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.
For the sealing API, none of this is needed. As long as the inode is owned by the uid who creates the memfd, you can pass it around and no-one besides root and you can open /proc/self/fd/$fd (assuming chmod 700). If you share the fd with someone with the same uid as you, you're screwed anyway. We don't protect users against themselves (I mean, they can ptrace you, or kill()..). Therefore, I'm not really convinced that we want this for memfd. At least no-one has provided a _proper_ use-case for this so far.
Hmm. Fair enough.
Would it make sense for the initial mode on a memfd inode to be 000? Anyone who finds this to be problematic could use fchmod to fix it.
I might even go so far as to suggest that the default uid on the inode should be 0 (i.e. global root), since there is the odd corner case of root setting euid != 0, creating a memfd, and setting euid back to 0. The latter might cause resource accounting issues, though.
--Andy