samba - Oct 2021 - domain-free multi-user use cases

On Wed, 2021-10-27 at 10:39 -0500, Patrick Goetz via samba
wrote:
> With all due respect, I think you're confused about how these things 
> must work, based on practical considerations. I urge you to go back
> and 
> re-read my first post in this thread carefully.  The issue is
> explained 
> there.
> 
> To reiterate an example I provided there (bitcoin), you either have
> a 
> central authority which is the final arbiter of deciding if someone 
> requesting a resource is actually the user they say they are, or you 
> don't.  If you don't have a central authority, then there must be
> some 
> other mechanism for determining this and those quickly become onerous
> or 
> complicated.  If you don't care about security, then problem solved: 
> just set file permissions to 777 and share the filesystem to anyone
> who 
> asks for it. This would generally not be acceptable in a business 
> context, but I know some smaller organizations who essentially have 
> their filesystem share configured this way: everyone is a fully
> trusted 
> user.
Would you please be specific about what leads you to think I am
confused? What have I written that is inaccurate?

A basic case of the proposed feature would be that the privileged user
of a client system (e.g. root) creates a remote mount using privileged
credentials on a remote system. This operation is currently supported,
but ownership information is not represented on the client mount. The
difference, representing the proposed support for multiuser, is that
the client would expose the true file owners in its local view. Doing
so requires a user mapping, which might be as simple as string matching
of names.

On 10/28/21 02:41, Eric Levy via samba wrote:
> On Wed, 2021-10-27 at 10:39 -0500, Patrick Goetz via samba wrote:
>> With all due respect, I think you're confused about how these
things
>> must work, based on practical considerations. I urge you to go back
>> and
>> re-read my first post in this thread carefully.  The issue is
>> explained
>> there.
>>
>> To reiterate an example I provided there (bitcoin), you either have
>> a
>> central authority which is the final arbiter of deciding if someone
>> requesting a resource is actually the user they say they are, or you
>> don't.  If you don't have a central authority, then there must
be
>> some
>> other mechanism for determining this and those quickly become onerous
>> or
>> complicated.  If you don't care about security, then problem
solved:
>> just set file permissions to 777 and share the filesystem to anyone
>> who
>> asks for it. This would generally not be acceptable in a business
>> context, but I know some smaller organizations who essentially have
>> their filesystem share configured this way: everyone is a fully
>> trusted
>> user.
> 
> Would you please be specific about what leads you to think I am
> confused? What have I written that is inaccurate?
> 
> A basic case of the proposed feature would be that the privileged user
> of a client system (e.g. root) creates a remote mount using privileged
> credentials on a remote system. This operation is currently supported,
> but ownership information is not represented on the client mount. The
> difference, representing the proposed support for multiuser, is that
> the client would expose the true file owners in its local view. Doing
> so requires a user mapping, which might be as simple as string matching
> of names.
> 
AFAIK, you can already do this with NFSv4 using nfsidmap and rpc.idmapd, 
with user mappings stored in /etc/idmap.conf.  I say AFAIK because I've 
never tried to use this feature and typically just make sure my users 
have the same uid on all systems (say by using a directory <:) ).

This doesn't cover Windows clients (is there still even an NFS 
implementation for Windows?) but I recall you saying you have an all 
linux environment.



-