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

On Sat, 2021-10-23 at 16:05 -0700, Jeremy Allison wrote:
> On Sat, Oct 23, 2021 at 03:59:42AM -0400, Eric Levy via samba wrote:
> > 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).
> 
> No, that's not true unless you are dealing with multiple servers
> and multiple clients. Even then, if all the clients had the same
> local users and all the servers had the same local users (i.e.
> user "Sam" on all clients maps to user "Sam" on all
servers)
> then you don't need a domain setup.
> 
> You can see why this would quickly become unscalable though :-).
> 
> Any client with multiple local users can attempt to connect
> to a Samba server as different users, so long as the different
> users are logged in simultaneously and try and access the
> same mounted drive.
> 
> E.g. For Windows,if "user1" mounts drive Z:, and then
"user2" tries
> to access Z: then the client will attempt a multiplexed
> SMB2_SESSIONSETUP + TREE_CONNECT to the server as "user2".
> 
> With no domain that means no kerberos so all logons will be
> done using NTLM, which isn't really what you want security-wise.
> 
> But if all clients have local users: user1, user2,..., userN
> and all servers have local users: user1, user2,..., userN
> and each user password is the same for that user across all
> clients and servers then each client can connect as multiple
> users, authenticating via NTLM and all will work.
> 
> You'd be nuts to try and do this for more than one or
> two users though, which is why NT Domains and AD Domains
> were invented.
It seems the first scenario you describe is simply several users each
creating their own single-user mount, that is, several simultaneous
uses in class (1). 

The second describes a Windows client, and it hasn't been explained
whether the same concept would transfer to a Linux client.

Can a Linux client mount (e.g. as root) a remote Samba share such that
files on the server owned by user1, user2, and so on, show
correspondingly on the client as owned by user1, user2, and so on?

On Sat, Oct 23, 2021 at 07:43:01PM -0400, Eric Levy via samba
wrote:
>It seems the first scenario you describe is simply several users each
>creating their own single-user mount, that is, several simultaneous
>uses in class (1).
>
>The second describes a Windows client, and it hasn't been explained
>whether the same concept would transfer to a Linux client.
>
>Can a Linux client mount (e.g. as root) a remote Samba share such that
>files on the server owned by user1, user2, and so on, show
>correspondingly on the client as owned by user1, user2, and so on?
man mount.cifs - options:

        multiuser
               Map  user  accesses to individual credentials when accessing the
               server. By default, CIFS mounts only use a single  set  of  user
               credentials (the mount credentials) when accessing a share. With
               this option, the client instead creates a new session  with  the
               server using the user's credentials whenever a new user
accesses
               the mount.  Further accesses by that user will  also  use  those
               credentials.  Because  the  kernel  cannot prompt for passwords,
               multiuser mounts are limited to mounts using sec=  options  that
               don't require passwords.

               With this change, it's feasible for the server to handle
permis?
               sions enforcement, so this option also implies noperm . Further?
               more,  when  unix extensions aren't in use and the
administrator
               has not overridden ownership using the  uid=  or  gid=  options,
               ownership  of  files  is presented as the current user accessing
               the share.