bugzilla-daemon at mindrot.org
2022-Aug-12 00:21 UTC
[Bug 3470] New: Cannot run SSH with a different effective userid
https://bugzilla.mindrot.org/show_bug.cgi?id=3470 Bug ID: 3470 Summary: Cannot run SSH with a different effective userid Product: Portable OpenSSH Version: v9.0p1 Hardware: 68k OS: All Status: NEW Severity: enhancement Priority: P5 Component: ssh Assignee: unassigned-bugs at mindrot.org Reporter: jbien at cisco.com Trying to run ssh from a setuid application, but it always tries to use the .ssh directory for the real user (which it cannot read), instead of the effective user. ssh.c is hard-coded to always use the UID to determine the home directory: pw = getpwuid(getuid()); Is there a security concern with allowing the user to specify their .ssh folder? Or at least use geteuid() instead of getuid()? Documentation made me believe the homedir was based on the USER environment variable ("USER Set to the path of the user's home directory"), but now I see the ENVIRONMENT section of the manpage specifies the variables it sets (unlike most ENVIRONMENT sections that mention variables that effect the operation). -- You are receiving this mail because: You are watching the assignee of the bug.
bugzilla-daemon at mindrot.org
2022-Aug-12 00:43 UTC
[Bug 3470] Cannot run SSH with a different effective userid
https://bugzilla.mindrot.org/show_bug.cgi?id=3470 Darren Tucker <dtucker at dtucker.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dtucker at dtucker.net --- Comment #1 from Darren Tucker <dtucker at dtucker.net> --- In the past, ssh(1) could be installed setuid root (for a couple of reasons mostly relating to hostbased and rhosts authentication). Referencing home directories by environment variables under those conditions would be a potential security problem. Rhosts auth is long gone, hostbased auth has used a small setuid helper (ssh-keysign) for many years, and a few years ago (in v7.8) we removed support for installing ssh as setuid. So yes there was a reason for it, but that reason is no longer there. Changing the behaviour would be a potentially incompatible change, however, so would need to be considered carefully. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug.