[Bug 1844] Explicit file permissions enhancement to sftp-server

[bugzilla-daemon at mindrot.org]

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

eb <email.bug at arcor.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |email.bug at arcor.de

--- Comment #10 from eb <email.bug at arcor.de> ---

Instead of patching in yet another complicating workaround, it could be
preferable and possible to solve the root of the problem.

The "specification" for the current default behavior seems to have been
a never completed draft, of a working group that has been canceled.



=== SPECIFICATION PROBLEMS ===

https://tools.ietf.org/html/draft-ietf-secsh-filexfer-13#section-7.6
> 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 is very badly worded.

1) The talking about server and client is actually really doing wrong,
it is not possible to specify correct permission handling with these
wrong terms. That is because correct permission handling depends on the
file sender and receiver (data transfer direction), not client and
server.

2) It is 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 only referring to bits that were explicitly defined
by the command (for which using a --preserve-permissions flag would be
an example).

So misconception 2) may really have broken SFTP for multi-user system
group directories. (Assuming the umask in effect for the SFTP server
process actually is 0002 on the server.)



=== PROPOSED SOLUTION ===

There is no point in applying a too strict nor too permissive umasks
from a file sending system on the file receiving system (for example
one may use User-Private-Groups with a default umask 0002).

Nor should any file permissions be copied verbatim by default. Instead,
as with all file creations, the default umask on the receiving side
needs to be responsible to ensure safe default file permissions at the
target location.



Thus, a more sensible specification could be:


1) By default, the file sending side MUST NOT send permission bits.

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

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

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

* This is to allow overriding the receiver's default umask policy, by
allowing the user to manually grant more or less permissions.  The
receiver's default settings always declare the permissions that are
safe at the particular location on the receivers side, i.e. also for
especially configured group directories, but there may be occasions to
manually grant more or less permissions.)

* The "should" still allows a receiver (e.g. a server) to apply further
rules, if the use-case requires this.)

---

Overall, this could eliminate most, if not all, reasons for the special
override patches that have been proposed here.

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