John Plocher wrote:
> Darren J Moffat wrote:
>> That is called an incompatible change for Solaris.
>
> Since there is more and more support for making OpenSolaris
> a "Major (but lets not be stupid when doing it) Release",
> I don't see this as a showstopper.
>
>> What if a customer already has an account with a uid/gid >= 100 and
>> we add "reserved" account ? Answer "BOOM! bad things happen".
>
> The same bad things happen if the user has MacOS and/or Linux
> systems on their network today.
>
> I'd argue that this is a place where "Linux Familiarity" trumps
> "the way we always have done things" and we should consider
> raising the reserved UID space. Having only a 100 reserved UIDs
> is getting to be a bit tight.
Reserved UIDs for this stuff is probably *not* the best solution. Some
kind of ephemeral IDs, or a separate numbering space that is guaranteed
not to be used with non-local services would be best. Since file
ownerships aren't at stake, if we did something like (and I'm not
suggesting this *particular* approach formally) use a 64-bit UID with
UIDs > 32 bits are assumed to be "ephemeral" or otherwise reserved for
local system use only, we wouldn't then need to worry about
interoperability.
IMO, there are already collisions between UIDs that are used across
systems. I've seen systems that publish low numbered UIDs in NIS, for
example, causing inter-system conflicts. The only UID that I've found
to be reasonably portable is 0.
-- Garrett
