[Bug 3252] New: file transfers break (mangle) secure/useful file permissions
bugzilla-daemon at mindrot.org
bugzilla-daemon at mindrot.org
Thu Jan 14 22:11:28 AEDT 2021
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.
More information about the openssh-bugs
mailing list