[Samba] domain-free multi-user use cases

[Eric Levy]

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.


>