UID_MIN & GID_MIN changed

["Jóhann B. Guðmundsson"]

On 05/25/2011 08:14 PM, Simo Sorce wrote:
> On Wed, 2011-05-25 at 20:04 +0000, "Jóhann B. Guðmundsson" wrote:
>> On 05/25/2011 06:14 PM, Toshio Kuratomi wrote:
>>> Coordination would be nice if we can decide on how we can sanely make
>>> changes to this.
>> I would think first is to reach consciousness on what the
> Do you mean consesus ? We are pretty conscious of the uid/gid problem
> space I believe :)
>

Yup I meant conscious and I was refering to the uid/gid range

>> reserved/system IDs are supposed to be once that has been done we can
>> start looking at what is the best approach to implement and or fix
>> things that might break because of it.
> Changing the reserved id space should break "only" new allocations on
> systems that may have used the newly allocated IDs already.
> The only way to fix that is to have the admin manually intervene after
> the error is brought to his attanetion.
>
> Of course a softer way to deal with this is to not change the defaults
> on upgrade if checks reveals IDs in the affected space. The problem is
> that it may not be easy to determine this, esp when centralized ID are
> also available via NIS/LDAP.
>
>> We admins that are in mixed *nix environment and are stuck with legacy
>> uid/gid already have to *fix* the idiocy being done in configs and
>> application where the min UID/GID is set to anything but 100 (
>> restricted range ).
> There is no need to insult developers that use defaults that are ok for
> 99% of the users and affect only legacy setups where poor decisions
> where made wrt uid/gid allocations.

I'm pretty sure that things looked differently 20 - 30 years ago which 
in my case is when those poor decisions as you call them were made.
( and encase anyone is wondering I was not the one that made those 
decisions, I only get the *luxury* of dealing with them on daily bases )

> No default will ever please everyone.
>

True true

>> Basically we whom are living in and running legacy/mixed OS environments
>> are fucked already the main thing here is to reach consciousness across
>> distro's and preferably *nix platforms so we dont be in this crappy
>> situation again after 10 - 20 or 30 years time..
> You are asking the impossible, its unreasonable to set the bar to make
> any change in this area to some sort of consensus that was not reached
> in the past 30 years. It is effectively stalling the process and
> preventing change. Which is unreasonable

Has there been any effort in trying to address this problem in the past 
thirty years?

What looks to me the mistake that lsb did in the first place was to 
reserved an id range for dynamic allocation by system administrators and 
post install scripts use.

I'm pretty sure if they had not done that and simply raised the bar on 
reserved id to something high enough let's say 5000 or more and forced 
everyone to apply for an id in the reserverd space we would not be 
having this problem today...

JBG