On Thu, Mar 27, 2014 at 11:56 AM, Jeremy Allison <jra@xxxxxxxxx> wrote: > On Thu, Mar 27, 2014 at 11:46:39AM -0700, Andy Lutomirski wrote: >> On Thu, Mar 27, 2014 at 11:26 AM, Jeremy Allison <jra@xxxxxxxxx> wrote: >> > >> > Amen to that :-). >> > >> > However, after talking with Jeff and Jim at CollabSummit, >> > I was 'encouraged' to make my opinions known on the list. >> > >> > To me, calling the creds handle a file descriptor just >> > feels wrong. IT *isn't* an fd, you can't read/write/poll >> > on it, and it's only done as a convenience to get the >> > close-on-exec semantics and the fact that the creds are >> > already hung off the fd's in kernel space. >> >> Windows calls these things "handles." Linux has "file descriptors," >> and there's plenty of precedent for things that aren't files. > > Sure, but there's a set of expectations around > fd's that these things don't satisfy - IO-ops. eventfd, timerfd, and signalfd barely satisfy those. namespace fds don't satisfy those expectations at all. And /proc/pid/fd is really quite useful for debugging. > >> > That way we can also make it clear this thing only has >> > meaning to a thread group, and SHOULD NOT (and indeed >> > preferably CAN NOT) be passed between processes. >> > >> >> If you want those semantics, then stick a struct pid * in there for >> the tgid of the cretor and make sure that current's tgid matches when >> you try to use it. >> >> I think they'd be more useful without that check, though. > > I'm more worried about leakage and unintended consequences > here. > >> BTW, what do you want to have happen on fork? I think they should keep working. > > Yeah, that's true. I want them to keep > working across fork, but not across exec > or any other method of fd-passing. > This seems like an unfortunate restriction to put in the kernel to prevent userspace from shooting itself in the foot. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
