This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
To be fair, we haven't presented Linus et al with an actual implementation to fix the kernel semantics cleanly. I have talked about some strategies and the response has been quite skeptical. But that was largely the case when talking about numerous other changes to correct Linux semantics to follow POSIX, and when I actually provided the implementations, convincing them to incorporate the code was more possible than initial reactions suggested. But, it's also the case that such an implementation is going to be a bit hairy, and I don't expect to get to it in the next couple of weeks. I won't argue against your desire to have some interim solution. There are a variety of problems with the half-assed user-mode simulation of the correct semantics. I'm pretty sure there is no way a user-mode implementation can actually be POSIX-conformant. I tend to agree that almost-correct is better than the status quo of known-wrong. But we should make sure that users are aware of the limitations of what we have now. The fundamental limitation of not having the kernel support the right semantics directly is nonatomicity: at some point in some race conditions, you will have one thread behaving under one UID and another thread behaving under a different UID in a way that is detectable (if not exploitable). The implementation using signals can also introduce some anomalies common to signal interruption (spurious EINTR returns and suchlike), which are more likely to be an issue than the nonatomicity (unless, of course, that can be badly exploited by an attacker). I have never been in favor of a per-thread ID extension. I am highly skeptical that we want to provide such an extension. I am even doubtful that nscd should be using it. If you want to add these extensions, please give a complete specification (in POSIX terms) of exactly what they mean. It is wholly unclear to me what the EUID of a thread distinct from the process's EUID means, and I would have to consider each and every reference to UIDs or privilege in POSIX to get a handle on it. The manifest semantics of the existing system calls in Linux 2.6 is something that creates real security problems if things like nscd start using it. Now any user can send signals to an nscd thread that is processing a query for its UID. Fortunately a user can't suddenly ptrace nscd--but those are just the first two things I thought to check, and again I would have to audit a lot of kernel code to really be sure what kinds of worms are in this can. AFAICT the useful thing that you are trying to have nscd do is just to assume the user's identity for purposes of filesystem and network access. That is an extension that seems at least somewhat sensible, unlike per-thread EUIDs, which is a total nightmare. For just this, Linux's setfs*id system calls implement it already and perhaps we should just be blessing their use in pthreads programs. Thanks, Roland
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |