[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: UID and GID generation



This is a nice idea. I think that it is somewhat important that,  this design issue is fixed 


------ Original message------

From: Martin Bammer

Date: Fri, Aug 12, 2016 17:30

To: debian-devel@lists.debian.org;

Subject:UID and GID generation


Hi,

I've got an issue with the generation of UIDs and GIDs when new users are added. By default UIDs and GIDs for users and user groups are values starting from 1000 (on Red Hat from 500). When a user is added the next free value is chosen.
The issue now is when the same user names are added on different machine in a different order. A very common example is a family where each family member has it's own computer. So for example on computer A the users are added in the order john, mary, dave. On computer B mary, dave, john.
Now John buys an external drive for backups and data sharing and formats it with ext4. Then John copies several private files to the external drive. Then Mary wants to do the same on her computer, but when she connects the external drive she can see John's files with user and group mary and she has full access to these files. A very bad design issue!
So my suggestion would be to change the default behavior of UID and GID generation to hash value calculation. Has values are computed by the user and group names as 32bit values on Debian (31bit on Red Hat). The minimum and maximum values should be configurable.
Here an example how UIDs and GIDs can be generated:

uidGen = hashlib.hashfunc()
uidGen.update(username)
uid = uidGen.digest()
# We have to check here if the uid is in the valid range and if no other user already has this uid.
while uid < lowerLimit or uid > upperLimit or uid in listOfUsers:
        uidGen.update(username)
        uid = uidGen.digest()

If we have no conflicts with other users before the while loop then the UIDs should be the same on all computers independent of the generation order.
IMHO the current implementation is a design bug which must be fixed.

Regards, Martin



Reply to: