The main() function for in ssh.c calls PRIV_END even when the user is unprivileged to start with. On several cloud 'Function as a service' platforms, including AWS Lambda and Heroku, this fails with with an "Operation not permitted" error. This appears to be to do with the way that sandboxing capabilities of these platforms restrict calls to seteuid() and the state of the real, effective and saved user IDs. It would be helpful if the PRIV_END and PRIV_START calls checked if there were any privileges to drop or gain and not call seteuid() if there is no privilege to be dropped.
Created attachment 3162 [details] PRIV_{START_END}: check if seteuid calls are needed before calling
does this work for you?
Looking at the specification for seteuid it looks like those platforms are not compliant. IEEE Std 1003.1 both 2004 and 2018 Editions specify the following reasons for seteuid to fail: The seteuid() function shall fail if: [EINVAL] The value of the uid argument is invalid and is not supported by the implementation. [EPERM] The process does not have appropriate privileges and uid does not match the real user ID or the saved set-user-ID. Neither of those seem to be applicable in this case though. It makes me wonder if there any reason to still support ssh being setuid at all these days. Certainly the only use cases I can think of are long dead.
The PRIV_START/PRIV_END code has been removed entirely including the setuid calls which should fix your issue: https://github.com/openssh/openssh-portable/commit/258dc8bb07dfb35a46e52b0822a2c5b7027df60a This will be in the 7.8 release. Thanks.
Close RESOLVED bugs with the release of openssh-8.0