On Fri, Aug 08, 2008 at 12:11:33PM -0700, Garrett D'Amore wrote: > 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.
That is certainly the easiest way to get some breathing room. > 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. Well, we already have ephemeral IDs, and more than enough. The issues to work out would be as I described earlier, and keep in mind that UFS wouldn't be able to deal with them (that also applies to tmpfs today, but tmpfs we can fix). Perhaps wortwhile, but first consider the economics: if Linux and MacOS X have effectively increased the reserved ID ranges enough for our purposes for the forseeable future then perhaps we can avoid the investment in an ephemeral ID approach. > 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. Heh.
