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

On Sat, 2021-10-23 at 20:31 -0700, Jeremy Allison via samba
wrote:
> 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.
One could imagine building a solution based on S4U2Proxy (constrained
delegation) to authorize one server to assert the identity of all the
users it holds.  That external to Samba tool (no need for us to be
involved) would just supply normal Kerberos tickets to the server for
each user, obtained with this protocol extension.

Of course, in this situation you would need an AD DC, thankfully we
have one built in!

Andrew Bartlett

-- 
Andrew Bartlett (he/him)        https://samba.org/~abartlet/
Samba Team Member (since 2001)  https://samba.org
Samba Developer, Catalyst IT    https://catalyst.net.nz/services/samba

On Sun, 2021-10-24 at 18:01 +1300, Andrew Bartlett via samba
wrote:
> On Sat, 2021-10-23 at 20:31 -0700, Jeremy Allison via samba wrote:
> > 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.
> 
> One could imagine building a solution based on S4U2Proxy (constrained
> delegation) to authorize one server to assert the identity of all the
> users it holds.  That external to Samba tool (no need for us to be
> involved) would just supply normal Kerberos tickets to the server for
> each user, obtained with this protocol extension.
> 
> Of course, in this situation you would need an AD DC, thankfully we
> have one built in!
I am not familiar at this time with these components, but it would seem
that the level of complexity from using such an external tool might
defeat the purpose of seeking to eliminate the need for a domain
server.