openssh bugs - Apr 2021 - [Bug 3252] file transfers break (mangle) secure/useful file permissions

https://bugzilla.mindrot.org/show_bug.cgi?id=3252

            Bug ID: 3252
           Summary: file transfers break (mangle) secure/useful file
                    permissions
           Product: Portable OpenSSH
           Version: 8.4p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: sftp
          Assignee: unassigned-bugs at mindrot.org
          Reporter: email.bug at arcor.de
                CC: bryonak at freenet.de, eknagy at omikk.bme.hu,
                    jjelen at redhat.com, redimido at gmail.com

Default SFTP transfers don't comply to the umask configurations of the 
receiving system. This leads to too permissive or too restriced file 
permissions on the receiving side if the umasks differ between the
systems.

For example, between a multi-user system with user-private-groups and 
group collaboration directories (umask in effect is 002) and a legacy 
system with an umask of 022.


It's wrong to applying too strict or too permissive file permissions. 
The permissions from one system may not be copied verbatim to the 
other system by default. (Don't have any useful meaning on the other
system.)

As with all file creations, only the properly configured default 
umask of a system can ensure safe and useful default file permissions.



=== POSSIBLE CAUSE: SPECIFICATION / INTERPRETATION PROBLEMS ==
https://tools.ietf.org/html/draft-ietf-secsh-filexfer-13#section-7.6
(This "specification" for the current default behavior actually seems
to have been a not yet finished draft, from a working group that has 
been canceled.)
> Implementations MUST NOT send bits that are not defined.
>
>   The server SHOULD NOT apply a 'umask' to the mode bits; but
should
>   set the mode bits as specified by the client.  The client MUST apply
>   an appropriate 'umask' to the mode bits before sending them.

This part of the specification seems broken, or at least its very
unfortunate 
wording seems to have contributed to confusion that had implementations
break correct permission handling.

1) The talking about server and client does not apply to file
permissions. 
It's not possible to specify correct permission handling with these
terms. 
Correct permission handling depends on the file sender and receiver
(data 
transfer direction), not client and server.

2) It's also a problem that "defined bits" can be misunderstood as
referring to the permission bits of the original *file* that is to be 
copied, instead of referring to bits that were explicitly defined by
the 
command that is used to *initiate* the transfer. (Using an explicit 
--preserve-permissions flag would only be one example of defined bits, 
that happens to reference the original file permissions.)





=== PROPOSED: IMPROVED DRAFT / IMPLEMENTATION ==

A fixed specification could be based on the simple principle
that "by default, a file copy is created just like every new file".

(The receiver's default umask declares the permissions that are 
safe at the particular location on the receivers side. 
But there may still be occasions to manually grant more or less
permissions.)


On the *sending* side of up- or downloads:

1) By default, the file sending side MUST NOT request enforcing 
   target permission bits. (Sending could occur, as long as this
   is not interpreted as requesting target permissions by the 
   receiving implementation.)

   * This allows the receiver's default umask policy to take effect
     by default.

2) The permission bits MUST be sent and their enforcement requested 
   only if explicitly requested by the command (e.g. with explicit 
   permissions or a --preserve-permissions option).


On the *receiving* side of up- or downloads:

3) If explicit target permission bits have been requested by the 
   command, then the receiver SHOULD NOT apply an 'umask' to the 
   mode bits; but should set the mode bits exactly as specified by 
   the command.

   * This is to allow overriding the receiver's default umask policy,
     by allowing the user to manually grant more or less permissions.  

   * However, the softened "should" still allows the file receiving
     side (e.g. a server) to configure custom rules, if the 
     particular use-case requires this.





__________

NB: Fixing this ugly permission mangling bug should eliminate most,
if not all, reasons for the special override enhancement patches
that have been proposed here.
(e.g. https://bugzilla.mindrot.org/show_bug.cgi?id=1844)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3252

--- Comment #1 from eb <email.bug at arcor.de> ---
Concerning the relevance:

As far as I know SFTP is the only remote filesystem (access) that is
not able to transfer and create files with proper use of the umasked
filepermissions in effect at their target location.

The users are authenticated, but the files that SFTP creates on behalf
of the users don't match the permissions that the files would get if
the user's were to create them locally, or through any other network
filesystem protocol.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3252

--- Comment #2 from eb <email.bug at arcor.de> ---
An example for a useful "custom rule" on a server as mentioned in 3b)
is to force a umask (i.e. the -m option patch already shipped with
fedora https://bugzilla.mindrot.org/show_bug.cgi?id=1844 )

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3252

--- Comment #3 from eb <email.bug at arcor.de> ---
Err, in my last comment it should of course read: "custom rule to force
*permissions*" not umask.

Other useful custom rules for a server that I could think of were to
force an umask and/or to force minimal permissions for the files that
the client can create.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.