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

Re: UID and GID generation



On Fri, Aug 12, 2016 at 07:37:43PM +0200, Philipp Kern wrote:
> On 2016-08-12 16:29, Martin Bammer wrote:
> >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.
> 
> I waited for you to complain that this is not the case and that files can't
> be accessed, but you did it the other way around and complain that they can
> be. If you want to keep files private on external drives (or drives in
> general), you use encryption. POSIX file permissions and ACLs do not help
> you there as anyone with root (say, on their personal device like a laptop)
> can just look at all of the files anyway. That assumption is as true on
> Windows with NTFS, by the way (unless you use EFS, which people generally
> don't).

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.

> >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.

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.

-- 
An imaginary friend squared is a real enemy.


Reply to: