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