[Samba] domain-free multi-user use cases

[Patrick Goetz]

On 10/23/21 08:39, 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.
>

A minor bug fix: the Directory Server also only hands over specifically 
requested information, so the clients will only have "some" of 
directory's data.  If user eric logs in on machine B, B will now keep 
track of eric's credentials for a specified while, but not patrick's, 
since patrick didn't successfully log in on B.


> 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.
>