Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 160089 - keyring support - glibc portion
Summary: keyring support - glibc portion
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-10 18:36 UTC by Tim Burke
Modified: 2007-11-30 22:11 UTC (History)
5 users (show)

Fixed In Version: 2.3.90-23
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-12-28 09:41:46 UTC

Attachments (Terms of Use)

Description Tim Burke 2005-06-10 18:36:10 UTC
Creating tracking bugzilla for the glibc changes which are required as part of
the keyring support for MSDW.  Refer to bug #130914 for description of the
kernel portion.

This change is to represent the new error codes and system call interfaces for
the kernel key management facility need backporting from FC to RHEL4.

Comment 4 Jakub Jelinek 2005-06-13 10:03:16 UTC
add_key etc. aren't exported from, and as they weren't exported until
2.3.5 release, they can't be exported as GLIBC_2.3.5 or earlier symver.
If they aren't added to 2.3.6, then they'd need to be GLIBC_2.4 symbols
(provided they are exported in CVS HEAD), but those symbols aren't appropriate
for RHEL4 nor FC{3,4}, otherwise rpm would happily install programs needing
other @GLIBC_2.4 symbols on RHEL4, but of course RHEL4 glibc can't provide them.

With the sys_errlist array it is tricky.  It is exported as an array, not as
say a pointer to an array or something like that.  Therefore, if binaries
use sys_errlist, they end up with a copy relocation and sys_errlist then
lives in their .bss section.  But obviously copy relocation needs to know the
size of the array.  ATM we do very ugly tricks, so that the various sys_errlist
symbols have the same base address in, but different sizes:
   200: 00cbd700   504 OBJECT  GLOBAL DEFAULT   27 sys_errlist@@GLIBC_2.3
   530: 00cbd700   492 OBJECT  GLOBAL DEFAULT   27 sys_errlist@GLIBC_2.0
   965: 00cbd700   500 OBJECT  GLOBAL DEFAULT   27 sys_errlist@GLIBC_2.1
The addition of those new errno codes would need another version, so suddenly
programs that use sys_errlist linked on RHEL4 U2 would not run on RHEL4 U1.

Comment 5 David Howells 2005-06-13 10:44:11 UTC
The sys_errlist problem is not very nice. How can a program cope with getting 
error codes beyond those listed in the array? I take it that it will just get 
a bad pointer. If so, that means you can't use an old glibc with a kernel that 
might return any higher error code if the program in question uses 
sys_errlist. Is there nothing in the userspace programming environment that 
indicates the size of sys_errlist[]? Not that anything would necessarily pay 
attention to it if it does exist... 

Comment 6 David Howells 2005-06-17 10:20:51 UTC
On the subject of relocations on sys_errlist... _why_ does the executable need 
to copy the sys_errlist[] array into its bss section at all? If a shared 
library uses it and the executable doesn't, that shared library accesses it 
directly out of glibc's data using a R_X86_64_GLOB_DAT or similar. Why does 
the executable have to use a R_X86_64_COPY relocation? It can certainly use 
R_X86_64_GLOB_DAT for other things, and it only needs the address... This 
business of copying things to the executable's bss seems to cause problems for 
backwards incompatibility, and it does seem to be unnecessary. 

Comment 7 Jakub Jelinek 2005-06-17 11:49:05 UTC
If you compile the executable code with -fpic/-fPIC, then sure, no copy
relocation is needed.  But otherwise it is, as the address of sys_errlist
needs to be known at static link time (well, there is -Wl,-z,nocopyreloc
but that results in DT_TEXTREL binaries and that is both undesirable and
SELinux policy will usually refuse to even start such binaries).

Comment 8 David Howells 2005-06-17 14:02:13 UTC
Why? I still don't see why it's necessary. Is this to avoid having to fix up 
the read-only/text segment of the executable? 

Comment 9 Jakub Jelinek 2005-06-17 14:07:05 UTC
Yes, of course.  That is both costly (startup time, the code can't be shared
anymore between different processes) and a security risk (if kernel can't forbid
making the code writable, because the dynamic linker must write to it, then
an exploit can make it writable too).

Comment 10 Ulrich Drepper 2005-06-20 15:51:58 UTC
And I stress again, I don't think any glibc code should be added.  It is not
necessary to export this functionality to 3rd part apps.  All the utilities we
ship which need to handle these new syscalls can use the syscall() function and
define their own constants.  We _might_ add the interfaces for RHEL5 but there
is no good reason to cause incompatibilities in the lifetime of RHEL4.

Comment 18 Jakub Jelinek 2005-12-28 09:41:46 UTC
glibc-2.3.90-23 and later define the error codes in an asm/errno.h header
prepended before the standard one (#include_next <asm/errno.h>
#ifndef ENOKEY
#define ENOKEY ...
).  So even the strings should be there.

Note You need to log in before you can comment on or make changes to this bug.