We just upgraded from openssh-5.0p1 to openssh-5.2p1 (linux) to find out that sshd changes its umask to drop group-write permissions. We deliberatly set umask 002 prior to starting sshd to allow group-writeable files to be created. I am not sure why this is done, but it breaks our setup and also breaks expected behaviour. Also I could not find any discussion on the list in the months leading up to this change, it only seems to be documented in the ChangeLog: 20080615 [...] - dtucker@cvs.openbsd.org 2008/06/14 17:07:11 [sshd.c] ensure default umask disallows at least group and world write; ok djm@ The packaged opensshd.init.in also assumes umask can be set prior to starting sshd. Therefor I propose to either undo this change (patch), or make it configurable in sshd_config.
What behaviour are you are expecting and what is this breaking for you?
Hi Damien, I am expecting to either have a umask setting in the configuration file, or, even better, to not change the umask so sshd will use the umask from the session that started it. On certain uploadservers we would like users to have a umask 002 by default. so that uploaded files from, say, windows will have group write permission. These users are often collaborating with others and have no clue about permissions. The current behaviour is a hard change in the software and no means to change it in configuration, that's an unfortunate combination.
(In reply to comment #2) > On certain uploadservers we would like users to have a umask 002 by > default. so that uploaded files from, say, windows will have group > write permission. These users are often collaborating with others and > have no clue about permissions. So you're talking about the umask of the eventual user's shell? or an sftp-only session? Can you set it in whatever shell startup you have? The reason for the change was that the sshd server itself could also create world writeable files when started with a permissive umask (eg the sshd.pid file). If it is sftp and you're using the external sftp server you could work around it by pointing "Subsystem sftp" in sshd_config to a shell wrapper that just sets the umask and execs the real sftp-server.
I am talking about both shell and sftp sessions. If a permissive umask would result in a writable pid file, then I feel the problem is with the umask and not with opensshd.
OpenSSH 5.4 will include an option to set an explicit umask for sftp sessions and there are a number of ways that a user may control their umask for shell/scp sessions (shell init files, PAM, etc.) We really don't want sshd to run with a loose or non-deterministic umask, so I think this bug can be closed.
Mass move of bugs RESOLVED->CLOSED following the release of openssh-5.5p1