On 6/28/20 6:48 PM, Grant Taylor wrote:
Does anyone have any experience with UUCP on macOS or *BSD systems that
would be willing to help me figure something out?
I ended up getting this to work.
I don't know if it was a macOSism or a *BSDism, but the root of the
problem was crossing between users via setuid / setgid in relation to
OpenSSH.
Two different versions of macOS behaved differently.
macOS Yosemite 10.10.5 runs the underlying ssh pipe command as the user
account that initiates the uucp / uuto / uux.
macOS Catalina 10.15.15 runs the underlying ssh pipe command as the
_uucp user, NOT the account that initiates the uucp / uuto / uux.
As such, on macOS Yosemite 10.10.5, I have to have the normal user's ssh
public key in the authorized_keys file on the remote system.
Conversely, on macOS Catalina 10.15.15, I have to have the _uucp user's
ssh public key in the authorized_keys file on the remote system.
I don't know why macOS Yosemite 10.10.5 and macOS Catalina 10.15.15 are
behaving differently, but they are.
These inconsistencies made identifying which client ssh config file --
nominally ~/.ssh/config -- was used cumbersome.
For some unknown reason, I couldn't rely on "~/" or defaults to specify
the _uucp user's key (Identity) file or the known_hosts file on macOS
Catalina 10.15.15, despite the fact that it was running as the _uucp
user. I ended up having to hard code the paths, as they were defaulting
to the original user account that initiated the uucp / uuto / uux.
I can only surmise that something is fundamentally different between
Linux and macOS in how it does things when changing user accounts via
setuid & setgid as I did not have any of these problems on multiple
Linux machines. I can further surmise that something is different
between macOS Yosemite 10.10.5 and macOS Catalina 10.15.15. I don't
know if this is related to System Integrity Protection or something else.
--
Grant. . . .
unix || die
--
Grant. . . .
unix || die
