Re: UID and GID generation

[Martin Bammer <mrbm74@gmail.com>]

> Actually, I do like this idea; obviously with reasoning contrary to the
> original report.  In any small organization or a family, where you have an
> ad hoc set of machines without centralized user management, it is nice to
> have consistent uids.
> 
> This helps with cases like moving a disk around.  Or, most of the times you
> need rsync --numeric-ids (or it will cause irreversible metadata loss),
> except for the times when you need the opposite.  With uids being the same
> no matter which of you originally set that box up, this problem is avoided.
> 
> Obviously, it doesn't scale well past a handful of users, but by then anyone
> sane will keep things organized in some way.

You always have the option to define an UID or GID manually when creating a new 
user or group. In addition the old algorithm should be kept so the admin has 
the option to choose how UIDs and GIDs are generated. The algorithm I've put 
in my first post is only a first suggestion. I'm sure this algorithm can be 
improved.

> I'd make the hash 16 bits rather than 32, to make it possible to copy them
> by hand without resorting to copy&paste or a piece of paper.  A compromise
> between hash collisions and readable numbers.  And there's no security loss,
> as there's no security beyond physical possession when moving an
> unencrypted disk -- or when mounting an untrusted filesystem that's not
> something dead simple like FAT.

The value range of generated UIDs and GIDs should be configurable. So if 
someone wants only small values he can configure this.

And what would be needed in addition if hash-ids would be implemented is a 
migration tool which helps to migrade UIDs and GIDs for all files in a file tree 
which have a specific UID or GID .

Regards,
Martin