Re: [LSF TOPIC] beyond uidmapping, & towards a better security model

[NeilBrown]

On Wed, 21 Feb 2024, Matthew Wilcox wrote:
> On Tue, Feb 20, 2024 at 07:25:58PM -0500, Kent Overstreet wrote:
> > But there's real advantages to getting rid of the string <-> integer
> > identifier mapping and plumbing strings all the way through:
> > 
> >  - creating a new sub-user can be done with nothing more than the new
> >    username version of setuid(); IOW, we can start a new named subuser
> >    for e.g. firefox without mucking with _any_ system state or tables
> > 
> >  - sharing filesystems between machines is always a pita because
> >    usernames might be the same but uids never are - let's kill that off,
> >    please
> 
> I feel like we need a bit of a survey of filesystems to see what is
> already supported and what are desirable properties.  Block filesystems
> are one thing, but network filesystems have been dealing with crap like
> this for decades.  I don't have a good handle on who supports what at
> this point.

NFSv4 uses textual user and group names.  With have an "idmap" service
which maps between name and number on each end.
This is needed when krb5 is used as kerberos identities are names, not
numbers.

But in my (admittedly limited) experience, when krb5 isn't used (and
probably also when it is), uids do match across the network. 
While the original NFSv4 didn't support it, and addendum allows
usernames made entirely of digits to be treated as numerical uids, and
that is what (almost) everyone uses.

It is certainly useful to mount "my" files from some other machine and
have them appear to have "my" uid locally which might be different from
the remote uid.  I think when two different machines both have two or
more particular users, it is extremely likely that a central uid data
base will be in use (ldap?) and so all uids will match.  No mapping
needed. 

(happy to be prove wrong...)

NeilBrown


> 
> As far as usernames being the same ... well, maybe.  I've been willy,
> mrw103, wilma (twice!), mawilc01 and probably a bunch of others I don't
> remember.  I don't think we'll ever get away from having a mapping
> between different naming authorities.
> 
>