On Wed, Aug 18, 2021 at 2:10 AM Yasha Karant <[log in to unmask]> 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.