[Samba] domain-free multi-user use cases

[Eric Levy]

On Sat, 2021-10-23 at 08:39 +0100, Nick Howitt via samba wrote:
> On 23/10/2021 06:28, Eric Levy via samba wrote:
> > On Fri, 2021-10-22 at 22:07 -0700, Jeremy Allison via samba wrote:
> > > On Sat, Oct 23, 2021 at 12:03:18AM -0400, Eric Levy via samba
> > > wrote:
> > > > In my earlier conversation in this group, I described my needs
> > > > as
> > > > follows:
> > > > 
> > > >    What I want is multiple users on the client accessing the
> > > > same
> > > > mount
> > > >    but with different permissions enforced for each. I want the
> > > >    permissions to reflect the permissions for the corresponding
> > > > users
> > > >    on the NAS.
> > > > 
> > > >    It seems by now it has been made clear that it is impossible
> > > > to
> > > >    achieve this result without some kind of domain server...
> > > 
> > > Isn't that the bog-standard standalone file server case,
> > > with user names on the client mapped into the same user
> > > names on the server ?
> > > 
> > > The clients can easily do multi-user mounts, both Windows
> > > and Linux.
> > > 
> > > I guess I don't understand exactly what you are asking
> > > for here.
> > > 
> > > In your scenario, where are the "users" defined ? How
> > > does a client have multiple users logged in ? Are
> > > these local users defined on the client ?
> > 
> > When I inquired earlier to this group, it was explained that
> > multiuser
> > mounts depend on a domain server, and this explanation is also
> > given in
> > the documentation. I think the standard standalone case is that all
> > files in the mount share the same owner viewed by the client,
> > perhaps
> > with some added support for special users such as "nobody". A mount
> > that shows different files owned by various regular users is not
> > supported. The reason is as you say, some mechanism is required to
> > support a user mapping, which currently is handled only by a domain
> > server.
> > 
> > The immediate need that interests me personally is that the same
> > set of
> > users are defined in the client and file server, with association
> > occurring by equivalence of names, that is, symbolic user
> > identifiers.
> > 
> > The proposed class (3) is much more general, deliberately so, as
> > its
> > definition is to include all cases not in the other two classes.
> > What
> > support might be available for various cases in an actual design is
> > obviously too detailed to discuss in this conversation. The purpose
> > of
> > this conversation is to explain my view that the cases currently
> > supported are limiting, according to my understanding and in my
> > view of
> > what is useful to me personally and presumably also more generally
> > for
> > many others in a very small but still multiuser environment.
> > 
> > 
> > 
> Isn't class 3 just a basic file server with no domain frills? All
> the 
> users will have to exist on the file server and preferably with the
> same 
> passwords as in Windows (as Windows tries the local username/password
> to 
> connect to the share initially). My distro (ClearOS) does that using 
> LDAP for the user database, but I'd be astonished if it were not
> easier 
> to set it up with basic Linux users. If server and client passwords 
> differ it may be easier to use "net use ...." to connect to the
> shares 
> initially but have Windows remember the share mappings or you use 
> Windows' Credential Manager.
> 
> I would guess that this setup is also the setup in many NAS's.

The most basic mount to a file server is single user, represented by
(1). I have come to understand, in part from a discussion in this
group, that a multiuser mount is not possible without the addition of a
domain server, represented by class (2). As explained, a multiuser
mount is one for which various files are owned by different users
within the same mounted view, and the differences in ownership in the
mounted view reflect the actual ownership of the server (though in
general a user mapping may be employed).

I am not sure whether your comments are suggesting a problem with my
understanding. I have yet to see either a consensus in this group or a
proof of concept that (3) is supported currently. It was explained to
me, based on my best understanding, that in fact it is not supported,
and the disappointment from the explanation was the reason I chose to
open this conversation. 

Note that a deployment that includes an LDAP server would seem to me to
fall under (2), as an LDAP server I think is a natural analogue to a
domain server. 

Maybe you would offer a few more details to support your case, so I
understand your idea, though as I say, for practical purposes in this
conversation, it seems to me that an LDAP server deserves to be counted
as a domain server.