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]

Re: setXid


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]