Bug 3252

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)