lkml.org 
[lkml]   [2000]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 32-bit UID support
    Eugene:

    > Can Chris or someone please tell me what is the reason behind leaving
    > __kernel_uid_t == short on x86 architecture, and adding
    > __kernel_uid32_t? To me, it sounds more reasonable to rather make
    > __kernel_uid_t == int and add __kernel_uid16_t == short for binary
    > compatibility things.

    That's what I did originally. Unfortunately, it breaks both libc5 and
    glibc. In the case of libc5, every time you compile a program, you are
    including header files from the kernel source tree (normally installed in
    /usr/include/linux and /usr/include/asm). If we were to change the types
    of uid_t and gid_t directly in the kernel, then anyone trying to compile a
    program would be using the wrong sizes and would end up with a miscompiled
    program.

    This is why we needed the following ugly construction in
    include/linux/types.h:

    #ifdef __KERNEL__
    typedef __kernel_uid32_t uid_t;
    typedef __kernel_gid32_t gid_t;
    #else
    typedef __kernel_uid_t uid_t;
    typedef __kernel_gid_t gid_t;
    #endif /* __KERNEL__ */


    > As a result of current status of things, 32bit uid support does *not*
    > become visible to the userspace when you rebuild glibc with the new
    > kernel source. To make it take effect, you also need to modify glibc
    > source, and in a rather illogical way.

    This is quite deliberate. If we were to change the type of __kernel_uid_t,
    and you recompiled glibc, you would *not* get a working glibc, you would
    get a glibc that worked only partially and caused various programs to
    crash. Even worse, if you tried to use this glibc on a system with an
    older kernel, every program would crash.

    Old versions of glibc simply do not expect the type of __kernel_uid_t to
    change.

    Instead, we added a new type, __kernel_uid32_t, and new system calls
    (sys_setuid32, sys_chown32, etc.). Old versions of glibc do not know about
    these, and will continue to work properly if compiled against newer kernel
    headers.

    Future versions of glibc will check to see if __kernel_uid32_t is defined
    when they are being compiled, and if so, will include everything that is
    necessary to make use of 32-bit UIDs on new kernels, and still work
    properly on older ones.

    I'll post a message to the kernel list when I have a patch for glibc 2.1
    for testing. The older patches on my web site do not yet work for the
    32-bit UID support now in Linux 2.3.


    Thanks,

    Chris Wing
    wingc@engin.umich.edu


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:55    [W:0.023 / U:0.168 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site