[Samba] domain-free multi-user use cases

[Patrick Goetz]

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.