I really wish this were workable, but it's not: you just can't cram
64 bits of data into 32 bits; if you could, we wouldn't have this problem.
(Yes, there are some workarounds (e.g. a per-process translation table),
but none of them work if the numeric uid is recorded outside the process.
And many won't work because what the user wants to do is map the numeric
UID onto some other number (employee number, SSN, whatever) which can
and does (when it fits) happen.
Donn
-----Original Message-----
From: Garrett Wollman [mailto:yyyyyyy@xxxxxxxxxxxxxxxxxxxxx]
Sent: Tuesday, March 13, 2001 8:41 AM
To: Geoff Clare
Cc: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
Subject: Re: Comments on XBDd5 ERN 322
<<On Tue, 13 Mar 2001 09:45:38 +0000, yyy@xxxxxxxxxxx (Geoff Clare) said:
> Another possible solution might be to run 32-bit binaries inside
> some sort of "sandbox" so they never see large PID or UID values.
Another possibility is for the standard library for 32-bit binaries to
perform some automatic mapping of *IDs from whatever the ``native''
format is, into something that fits in a long. (This is perhaps the
same thing as you meant to say, but ``sandbox'' to me means something
different.)
-GAWollman
|