These are NOT my demands -- these are standard ergonomic engineering
approaches. This is why the operation of a road vehicle is the same in
all modern vehicles -- save for upon which side of the road one drives
("right" vs "left" hand). As a counter example, one of my colleagues
has been using MS Office XP for a long time. She was forced to convert
to a later MS Office, and the controls have changed -- as she stated
"why did they hide the open dialog, and the word count is moved to a
completely different ... ". Thus, I use MATE and sometimes an actual
terminal (not a GUI) CLI interface, neither the current Gnome nor KDE
(originally, an interface "clone" of Unix CDE). For CIFS, it appears
that there is no equivalent of MATE for "traditional unix/bsd/linux
commands". There are well understood reasons for a significant change
in a control interface -- motor vehicles need a different interface than
a "beast of burden" drawn vehicle, the invention of saddle and stirrups
made major improvements to horse riding (but there a still persons who
use the older technology).
On 8/18/21 03:36, Nico Kadel-Garcia wrote:
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.
