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