From: gtaylor at tnetconsulting.net (Grant Taylor)
Subject: [COFF] UUCP on macOS / *BSD
Date: Wed, 1 Jul 2020 11:32:03 -0600 [thread overview]
Message-ID: <9062bea2-e260-5d8c-be71-155789327da0@spamtrap.tnetconsulting.net> (raw)
In-Reply-To: <e74ccf48-2eb7-3f4f-856b-4098ad7cc1cc@tnetconsulting.net>
On 6/28/20 6:50 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200701/daf260d8/attachment.bin>
prev parent reply other threads:[~2020-07-01 17:32 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-29 0:50 gtaylor
2020-06-29 15:37 ` lm
2020-06-29 16:13 ` gtaylor
2020-07-05 6:30 ` dave
2020-06-29 15:53 ` arrigo
2020-06-29 16:42 ` gtaylor
2020-06-29 17:20 ` clemc
2020-06-29 20:06 ` gtaylor
2020-06-29 20:59 ` clemc
2020-06-30 2:26 ` rtomek
2020-06-30 3:19 ` gtaylor
2020-06-30 3:26 ` rtomek
2020-06-30 3:46 ` rtomek
2020-06-30 3:50 ` gtaylor
2020-06-30 3:47 ` gtaylor
2020-06-29 17:22 ` arrigo
2020-06-29 20:18 ` gtaylor
2020-06-29 20:31 ` gtaylor
2020-07-01 17:32 ` gtaylor [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9062bea2-e260-5d8c-be71-155789327da0@spamtrap.tnetconsulting.net \
--to=coff@minnie.tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).