From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16910 invoked by alias); 20 Sep 2004 00:27:32 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 16894 invoked from network); 20 Sep 2004 00:27:32 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 20 Sep 2004 00:27:32 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8K0RWli004496 for ; Sun, 19 Sep 2004 20:27:32 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8K0RHr28972 for ; Sun, 19 Sep 2004 20:27:17 -0400 Received: from [10.0.1.84] (drepper.cipe.redhat.com [10.0.1.84]) by lacrosse.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8K0RBa04742 for ; Sun, 19 Sep 2004 20:27:12 -0400 Message-ID: <414E23D5.50502@redhat.com> Date: Mon, 20 Sep 2004 00:27:00 -0000 From: Ulrich Drepper Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a4) Gecko/20040915 MIME-Version: 1.0 To: GNU libc hacker Subject: setXid X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2004-09/txt/msg00068.txt.bz2 -----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-----