setXid

setXid

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I implemented finally an especially horrible part of POSIX: setXid
affecting the whole process.  The kernel people refuse to add support so
we have to do it at userlevel.  It is implemented by integrated over the
threads in the process, sending a signal, and having the signal handler
make the system call.

There is no error checking aside from the calling thread's call.  If
this call succeeds all others better succeed, too.  Otherwise the
programmer screwed up the process' state or the system is faulty.

To achieve this functionality the libc's setXid functions had to be
extended.  What previously had been a simple syscall is not a function
which calls the libpthread callback if it exists.  I cleaned up
(hopefully) the sparc code a bit.  The result is tested on x86, x86-64,
and ppc64.  ppc32 and ia64 should work, too.

The other archs need some love.  I introduced a new macro
INTERNAL_SYSCALL_NCS which is just like INTERNAL_SYSCALL, but the first
parameter can be a non-constant value.  I.e., INTERNAL_SYSCALL can be a
wrapper which simply adds __NR_ to the first parameter.  This needs to
be done for all archs supporting nptl.

The previous functionality of setXid was useful, as could be seen in
nscd.  Support for this functionality is now provided by a set of new
functions pthread_setXid_np.  I have decided not to get
pthread_getXid_np functions since they are only good for symmetry.  A
thread can only query its own IDs, not that of the mystical "process".
But I added the interfaces to LinuxThreads as well, mainly to help nscd.
 With LT setXid and pthread_setXid_np are equivalent.

Since the incorrect old setXid behavior was documented there is no need
to provide compatibility for programs which expect setXid to change only
the threads permissions.  This has always been wrong so screw those who
rely on it.  They'll have to change.  We have not lost any functionality
so this is not problematic.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFBTiPV2ijCOnn/RHQRAlIqAJwL/EtUkOOE18cai1lLlpyXx079rACdFa1d
xNU7N8xtpUUU85iUgQ3cEFs=
=TsMB
-----END PGP SIGNATURE-----

Re: setXid

[Roland McGrath]

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

Re: setXid

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roland McGrath wrote:
> To be fair, we haven't presented Linus et al with an actual implementation
> to fix the kernel semantics cleanly.

I have exchanged a lot of emails on this topic with Linus and several
others.  The main point they disagree with you is ...


> I have never been in favor of a per-thread ID extension.

They definitely want to preserve this and therefore any kernel solution
is as nonatomic as the userlevel implementation. (not my analysis).

I think this is as good as we'll get it any time soon (or ever).

- --
? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFBTy+Y2ijCOnn/RHQRAp0kAKCMvNPxm3G55EXRmC6I7pP0+iVoVACgkCIB
4OCcjhSMSz+1NE/NM7nrDP8=
=mwIF
-----END PGP SIGNATURE-----

Re: setXid

[Roland McGrath]

> > I have never been in favor of a per-thread ID extension.
> 
> They definitely want to preserve this and therefore any kernel solution
> is as nonatomic as the userlevel implementation. (not my analysis).

Like I said, they haven't been presented with an implementation yet.  What
I would propose would allow such an extension and also implement correct
semantics when you are not using it.  It's pointless to speculate about
what others would or wouldn't say in circumstances that don't exist yet.

> I think this is as good as we'll get it any time soon (or ever).

Assuming you are talking about the simulation of almost correct semantics,
that may be.  My point about that was that we should make sure that people
are aware of the "almost" and what it means.

You did not respond at all to my objection to your glibc extension
functions.  Please say something about how you intend these to be
acceptable features.  As they stand, it's necessary for me to absolutely
refuse to cooperate with their inclusion in glibc, and warn people away
from using nscd as it is.  Let's talk about what features we really do
want, and about getting them fully specified and securely implemented.


Thanks,
Roland

Re: setXid

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roland McGrath wrote:

> Like I said, they haven't been presented with an implementation yet.

I actually did.  I had all accesses to the values wrapped in macros,
then add a pointer, and have them, on demand, point to one single
variable in the thread group struct.

>  What
> I would propose would allow such an extension and also implement correct
> semantics when you are not using it.

You'll probably come up with the same method.  Have fun!


> You did not respond at all to my objection to your glibc extension
> functions.  Please say something about how you intend these to be
> acceptable features.

I don't understand the problem.  This extensions just provide a way to
access the behavior which has been in use forever.  Whenever I brought
the setXid topic up some people said "why multi-threaded program needs
the existing behavior".  These extensions are honestly as well defined
(or better) than the POSIX mandated behavior and they are necessary for
people who actually want the behavior (at least for migration purposes).
I see no problem at all.  If another OS does not provide the
functionality the functions can fail.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFBTzsp2ijCOnn/RHQRAt3GAJ9ToOogBS9phmUqF2htpYFNq60PrQCfZd62
mv70VcGJt4DO3O8yZZM+c/E=
=z0EN
-----END PGP SIGNATURE-----

Re: setXid

[Roland McGrath]

> These extensions are honestly as well defined (or better) than the POSIX
> mandated behavior and they are necessary for people who actually want the
> behavior (at least for migration purposes).

Sorry, that is just totally wrong.  Tell me right now exactly what they do,
I dare you.  You can't, because we don't know.  Like many parts of Linux,
this has always been a mess for the multithreaded cases and unclear what
many of the semantics are.  People have been coping with it, yes.  That
doesn't mean we want to say that this status quo is good enough.  It's not.

> I see no problem at all.  If another OS does not provide the
> functionality the functions can fail.

No other OS could provide the functionality, because noone knows what it is!
I demand a coherent specification for every API in glibc.  Period.


Thanks,
Roland