bugzilla-daemon at mindrot.org
2021-Jan-14 11:11 UTC
[Bug 3252] New: 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.
bugzilla-daemon at mindrot.org
2021-Apr-01 16:39 UTC
[Bug 3252] file transfers break (mangle) secure/useful file permissions
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.
bugzilla-daemon at mindrot.org
2021-Apr-01 17:09 UTC
[Bug 3252] file transfers break (mangle) secure/useful file permissions
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.
bugzilla-daemon at mindrot.org
2021-Apr-01 17:18 UTC
[Bug 3252] file transfers break (mangle) secure/useful file permissions
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.