public inbox for libc-hacker@sourceware.org
 help / color / mirror / Atom feed
From: Ulrich Drepper <drepper@redhat.com>
To: GNU libc hacker <libc-hacker@sources.redhat.com>
Subject: setXid
Date: Mon, 20 Sep 2004 00:27:00 -0000	[thread overview]
Message-ID: <414E23D5.50502@redhat.com> (raw)

-----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-----

             reply	other threads:[~2004-09-20  0:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-20  0:27 Ulrich Drepper [this message]
2004-09-20 19:20 ` setXid Roland McGrath
2004-09-20 19:29   ` setXid Ulrich Drepper
2004-09-20 19:50     ` setXid Roland McGrath
2004-09-20 20:19       ` setXid Ulrich Drepper
2004-09-20 20:26         ` setXid Roland McGrath

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=414E23D5.50502@redhat.com \
    --to=drepper@redhat.com \
    --cc=libc-hacker@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).