Once you consider interoperability concerns, there is a potential
different problem involving UIDs, which is that locally managed *names*
can collide with network administered *names*.
It seems to me, that a worthy project would be to identify a way for
these daemons that have local needs to use IDs *and names* that can be
used without impacting network administered names. Although any new
practices here might implicitly break "familiarity", since nobody else
deals elegantly with this particular problem.
-- Garrett
Darren Reed wrote:
> Garrett D'Amore wrote:
>
>> Jyri Virkki wrote:
>>
>>>
>>> On Aug 9, 2008, at 3:16 PM, Glenn Brunette wrote:
>>>
>>>>
>>>> other OpenSolaris instances. This was the concern that two
>>>> OpenSolaris
>>>> systems with software deployed in different orders could end up with 2
>>>> accounts having the same UID. This is bad and has caused a great deal
>>>> of problems in the past.
>>>
>>>
>>> Two [different] accounts with the same numeric uid on a system would
>>> certainly be a problem, but that wasn't the topic at hand.
>>>
>>>> I think that the Debian example was provided to illustrate that
>>>> starting
>>>> with UIDs > 1000 for user accounts would be a way of being consistent
>>>> for reserved vs. non-reserved ranges in a heterogeneous way.
>>>
>>>
>>> Indeed it was, but coincidentally it also brought an example where
>>> most daemon uids are assigned first-come-first-served and it seems
>>> to work just fine (as a long-time admin of multiple Debian boxes
>>> I've never encountered any issues nor do any potential ones come to
>>> mind).
>>>
>>> (+1 on raising the limit to 1000 though, that makes sense. Some
>>> Debian info here:
>>> http://www.debian.org/doc/manuals/system-administrator/ch-sysadmin-users.html)
>>>
>>>
>>
>>
>> Raising the limit makes sense. However, I'd also recommend that we
>> try to avoid actually *using* numbers greater than 200. (And for
>> now, 100.)
>>
>> Historically, didn't useradd create accounts starting at 101?
>
>
> Can we pull the configuration of the UID range that IPS uses out of
> the application and into a file, such as /etc/default/ips, thereby making
> it possible for people to edit/configure what their local policy should
> be for this task?
>
> And maybe for now ips should just return an error if there are no
> free uid's under 100 and ask the administrator to do something about
> the problem (and make suggestions on what to do)?
>
> But...
>
> What do we do if we get 25 or 26 new PSARC/LSARC cases in the next
> n months/weeks that all want to add a new uid for an application?
> Do we simply say "tough luck" to the 25th?
>
>
> The real problem we have is that people have built network environments
> where uids starting at 101 have been used for user accounts and they'll
> expect those to keep working (yes, I've worked on such networks.)
> While IPS might attempt to answer the question for OpenSolaris,
> where does that leave the Solaris Express DVDs of build X?
> Sure, they're unsupported, but shouldn't they at least work?
>
> Is there any reason why we shouldn't say back to the openldap project
> that you're uid 10000001, instead, or something else like that?
>
> Or in light of people starting at 100 and working up, should we start
> at 999 and work down, if we assume that only smaller networks will
> have ever used 101-999?
>
> In short, I think the ARC needs to decide on what policy we're going
> to move forward with irrespective of what IPS does (or doesn't do),
> including an EOF/EOL about uid space between 100-1000 as part of
> the next major release.
>
> Darren
>
