[lkml]   [1998]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: High UID support for Linux
    H. Peter Anvin writes ("Re: High UID support for Linux"):
    > [When uid_t and gid_t change, it will be useless for libc4/5 users]
    > >
    > > Unless, of course, they rewrite libc to take advantage of these new
    > > system calls.
    > >
    > Not that easy... the datatypes themselves would have to change, which
    > means the old binaries would be useless. And at that point, they
    > might as well just switch to glibc.

    They can't switch do glibc if they don't have the source, or if the
    source can't be compiled any more (eg. they wrote it in C++ and the
    language changed under their feet).

    I think its reasonable to require that essential system programs on a
    system that uses uids >= 65536 are linked with glibc2, but it is
    desirable that programs that users have imported from other Linux
    systems continue to work.

    A slightly horrible solution to this is to have the libc fake the
    result of getpwuid by remapping all uids >= 65536 to a uid reserved
    for this purpose. getpwuid can then map the result back to the user's
    real uid, which will allow getpwuid(getuid()) to give the right answer
    _for the current user_. Clearly, this approach is a disaster for file
    archiving programs etc, so it might want to not have that behaviour by
    default, but it will work for many applications that are only
    interested in the user that called the application.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

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