[Samba] domain-free multi-user use cases

[Rowland Penny]

On Sun, 2021-10-24 at 03:20 -0400, Eric Levy via samba wrote:
> On Sat, 2021-10-23 at 08:39 -0500, Patrick Goetz via samba wrote:
> > On 10/23/21 00:12, Eric Levy via samba wrote:
> > > In particular, I believe that one feature of the latter
> > > deployment,
> > > as
> > > well as the former, is that the file server is configured to
> > > recognize
> > > a domain server as part of the overall deployment. Suppose you
> > > wish
> > > to
> > > configure a client for a file server that has no association with
> > > a
> > > domain server. Under such circumstances, I believe any use case
> > > falls
> > > under class (1), which precludes the client creating a multiuser
> > > mount.
> > > My argument largely centers around the observation that a
> > > multiuser
> > > mount only may be realized through support for a proposed use-
> > > case
> > > class (3).
> > > 
> > > 
> > 
> > Samba can most definitely do what you're trying to do.
> > 
> > I think the confusion here has to do with the separation of 
> > responsibilities. There are two separate things necessary in order
> > to 
> > insure secure filesystem mounts in a multi-user environment: 
> > authentication and authorization.  They're not the same thing. 
> > *Authentication* involves a challenge requiring you to prove that
> > you 
> > are indeed the user you're saying you are, and *authorization* is
> > the 
> > determination of whether or not this particular user has access to
> > a 
> > particular resource.  You will agree that both of these are
> > absolutely 
> > necessary.  You can have erics-top-secret-file on a shared
> > filesystem 
> > with permissions locked down so that only eric can view it, but
> > this 
> > doesn't do you any good if anyone can pretend to be eric, right?
> > 
> > So step 1: you must have a system for authenticating users. OK, how
> > do 
> > you do this? Traditionally, in UNIX-like systems there are files on
> > the 
> > machine detailing user accounts and what the authentication
> > challenge
> > is 
> > that must be met. This works splendidly, but what do you do if you
> > have 
> > 100 or more systems and you want the same user names and
> > authentication 
> > challenges on all these systems?  You can certainly copy the files 
> > encoding this information around to all systems, but that can
> > become 
> > onerous (pre CMS), as any time you introduce a new user or change
> > a 
> > challenge, this information must be updated on all the
> > systems.  This
> > is 
> > why Sun Microsystems invented NIS. NIS also worked splendidly, but
> > it 
> > was low security and structural inflexible. Hence the introduction
> > of 
> > LDAP, which Microsoft co-opted as a component of an Active
> > Directory 
> > server, and which linux-only systems use in the form of openLDAP, 
> > FreeIPA/idM, etc.
> > 
> > This is quite a broad overview, but you get the idea: the point of 
> > having a Directory is having a single place where you keep track of
> > all 
> > authentication information.  Could you do this without a server,
> > with 
> > all machines somehow sharing credentials in the background? Sure,
> > of 
> > course, but why would you want to?  Often times when people have 
> > physical access to isomorphic authentication files, this affords 
> > opportunity to crack the secrets of these files. So if all your
> > machines 
> > are sharing physical credential files and one of these machines is 
> > compromised, the hacker now has a copy of all your credentials.
> > It's 
> > generally better to keep these things locked up behind multiple
> > doors 
> > where only a very small number of people have keys. And that, in a 
> > nutshell, is what a directory server is. Could you somehow have
> > the 
> > authentication system distributed agnostically across all
> > participating 
> > machines? Yes, again, but oh, the complications. Think of this
> > like 
> > bitcoin: yes, you can have a secure "ledger" without a central 
> > authority, but managing this consumes more electricity than the
> > entire 
> > country of Argentina!
> > 
> > What about authorization? Filesystems have the ability to store
> > metadata 
> > about which users (or groups of users) should or shouldn't have
> > access 
> > to any particular resource, and what this access means. Is the user
> > eric 
> > able to read the our-shared-proposal file?  Yes.  Should user eric
> > be 
> > able to edit or delete the our-shared-proposal file?  That's a
> > different 
> > question; maybe yes, maybe no.  But in any case that's a feature of
> > the 
> > filesystem being shared. In particular, if I have a folder on
> > machine
> > A 
> > which I share with machine B, when someone on machine B wants to
> > access 
> > a file from this share, machine B asks machine A if that user has
> > the 
> > appropriate credentials to do so. A's got the metadata, so just ask
> > A 
> > before proceeding.
> > 
> > One very important detail is that the metadata detailing
> > authorization 
> > is stored *numerically*.  All the filesystem knows, for example, is
> > that 
> > a user with numeric ID 1562224677 is the owner of the file foobar.
> > The 
> > association
> > 
> >      1562224677 = eric
> > 
> > is made using either the aforementioned authentication files or,
> > again, 
> > by a directory server.
> > 
> > If you're eric with UID 1001 on a different system, guess what?
> > That's a 
> > different eric, whether you think so or not. You'd have to tell
> > the 
> > system these are the same erics somehos (e.g. Canonical's 
> > /etc/subuid|subgid system for containers or NFS's or Samba's
> > idmap).
> > 
> > The reason I bring this up is that this technically means if you
> > type 
> > `ls -l` in a shared folder context, the name of the owner of each
> > file 
> > must be looked up against the directory server.  Isn't this going
> > to
> > be 
> > terribly slow, say, when listing a folder containing several
> > thousand 
> > files for each of which the user owner name must be looked up? And
> > the 
> > answer is yes, this is going to be terribly slow, which is why
> > typically 
> > the credentials are cached locally on client machines.  "Aha!", you
> > now 
> > exclaim, "so the credentials are on every machine ANYWAY!" Not
> > exactly: 
> > they're share in such a way (i.e. are encrypted) so as to not be
> > useful 
> > to anyone with physical access to the machine. The Directory Server
> > is 
> > not just handing over a copy of the credentials files, it handing
> > them 
> > out with invisible ink and the client system has to use it's own
> > magic 
> > lemon juice to see them.
> > 
> > tl;dr: yes, you can do this with Samba, but there are other
> > factors 
> > involved as well. Thinking about this in terms of authentication
> > and 
> > authorization will clear up most confusion.
> 
> I understand, but introducing authentication as distinct from
> authorization begs the question of whether access to each system
> would
> occur through common credentials. I have not given such as a
> requirement. For my immediate case, I had in mind that users already
> having separate accounts on each node, the administrator would
> configure a mount to mirror privileges from the server to the client,
> without also mirroring credentials.

It sounds like you already are running a workgroup, if so, you probably
will not want to hear this, but running a domain is easier. Just one
place to maintain users and groups.

Rowland