SCIENTIFIC-LINUX-USERS Archives

August 2021

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Yasha Karant <[log in to unmask]>
Reply To:
Yasha Karant <[log in to unmask]>
Date:
Tue, 17 Aug 2021 23:10:02 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (53 lines)
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 
(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 
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.

On 8/17/21 8:56 PM, Nico Kadel-Garcia wrote:
> On Tue, Aug 17, 2021 at 11:21 AM Yasha Karant <[log in to unmask]> wrote:
>>
>> This is a poor design decision on the part of the Linux systems
>> implementers, as it breaks backward compatibility.  There is no reason
>> that an "auto-translator" from CIFS to what has been used in
>> unix/BSD/linux for a very long time should not have been implemented.
> 
> Please do not say why work should have been done that you haven't
> tried to do yourself. CIFS, for example, supports multiple layers of
> both username and group based permissions, with more complex
> inheritance, ordered layers of "permit" and "deny" for each user or
> group, and considerable awkwardness resolving them that costs
> development, time, resources, and can cost a lot of tearing out of
> hair when trying to transform it to POSIX style permissions.
> 
> CIFS was not designed for UNIX. It was designed for Windows
> file-sharing, which has quite a few different distinctions due to the
> previous VFAT or more modern NTFS filesystems which underly windows
> filesystems and their capabilities.
> 
> NFSv4 ACL's come close to these permissions, but managing those in the
> Linux world is a serious pain in the ass. Samba does a pretty good of
> transforming underlying POSIX filesystems into CIFS compatible access,
> 
>> Although this practice is not uncommon in the profiteer sector as
>> planned obsolescence for cash flow and other fiscal measures dominate,
>> and for which the customers have very little control (the typical EULA
>> is similar to the Godfather's offer you cannot refuse), it should be
>> different in the open systems source code sector.  Has anyone written a
>> script that converts "old" into CIFS?
> 
> CIFS is not the server. CIFS is the protocol. If the setups of the
> server has changed, that's the server or the server configuration.
> You'll need to negotiate that with the server admins.
> 

ATOM RSS1 RSS2