[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.097 / U:3.224 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site