On Wed, Aug 18, 2021 at 2:10 AM Yasha Karant <ykar...@gmail.com> wrote: > > Although I was not involved with the specification of CIFS, nor with the > design or implementation of CIFS on open systems, I respectfully > disagree with at least some of your conclusions. In a top-down entity
Then your demands should not carry much weight. I've been porting Samba and related tools to UNIX systems since roughly 1993, and I can tell you that mapping the permissions of the underlying filesystems which SMB and later CIFS were designed to emulate into the Linux world is and will remain awkward. The UNIX and Linux authors who wrote Samba, the ancestor toolkit to cifs-utils, to did not design CIFS or its ancestor SMB. Microsoft did. Mapping UID and GID to idmaps, and handling the hierarchy of permissions, is a pain in the keister and the complexities often ignored as unwelcome or undesirable in a UNIX environment. If you don't like an architectural selection by the authors of cifs-utils, or Red Hat's or SuSE's architecteral implementaitons, hop over to the Samba mailing lists where the subtleties of CIFS are a better subject. SL is just a rebuild of RHEL: you might take it up with Red Hat. It's not fair to kvetch at Scientific Linux supporters about it. > (totalitarian dictatorship, clandestine or military service, > corporation, authoritarian theocracy, etc), the designated decision > maker/s decides as to what is allowed or not, including not permitting > backward compatibility. Would ignoring a protection mode enhance Input saying "you shoulda aughta done it this way" bears very little weight compared to that of actually picking up the tools, reviewing the issue, and seeing if it works. cifs-utils used to be part of Samba, and got factored out for good reasons, but has in general been very well behaved. It's working well in literally millions of devices around the world. If you or someone else with CIFS issues has a problem, I'll recommend the Samba mailing lists. > security by imposing a different access and security model? Perhaps, or > even definitely yes. However, the fact stated by the posting person > that SuSE did emulate a perhaps-obsolete security model under a > subsequent security model does seem to indicate that SuSE had a more > universal implementation of backward compatibility than what was > observed with EL. If the posting was in error and SuSE does not permit > such backward compatibility (perhaps with a warning message), then SuSE > as well as EL is not backward compatible. SuSE... has made some strange architectural decisions at various times. Rather than holding forth on the moral and intellectual failures of people you've not met or tried to collaborate with, perhaps you could grab a VM and actually try it. Contribute to the understanding, rather than decry someone else's work. Me? I've got samba backporting for RHEL 7 and RHEL 8 public repos to update. I'm hoping they've gotten the MIT Kerberos integration straightened out enough to use for RHEL effectively. I've not been backporting it to SL because there's not going to be an SL 8.