Is anyone using UUCP on macOS?

I'm running into some problems and would appreciate bouncing some ideas
off of someone else.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From somewhere in cyberspace, Grant Taylor <[email protected]> said: >Is anyone using UUCP on macOS?

I'm running into some problems and would appreciate bouncing some ideas
off of someone else.

What problems are you running into? Other than filesystem quirks (UUCP
temp filenames or target filenames might be case sensitive, which would
cause a surprise when running on HFS), or setting up a daemon via Launchd,
I don't think there are that many MacOS-specific issues that would trip
you up.
--
Ed Ravin | Warning - this email may contain rhetorical
| devices, metaphors, analogies, typographical eravin@ | errors, or just plain snarkiness. A sense of panix.com | humor may be required for proper interpretation.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/30/20 9:42 AM, Ed Ravin wrote:

What problems are you running into?

Running uucico as anybody other than the _uucp user (Apple has
apparently renamed "uucp" to "_uucp") will end up with failed
connections, I believe related to a line error. Yet the exact same configuration and uucico command work just fine when run as the _uucp
user. This may be related to what line / port type that I'm using; pipe
to ssh.

This underlying issue also manifests itself when running uucp, uuto, and
(I assume but have not tested) uux as they kick off a uucico process
unless told not to do so.

Either allowing the failing call to time out (< 2 minutes) or killing
it, and then subsequently running uucico as the _uucp user transfers
files correctly, both sending and receiving.

I'm trying to ascertain why uucico fails when started by someone other
than the _uucp user. I don't know if this is something specific to
macOS Catalina 10.15.15 and / or a difference with *BSD vs Linux where
I'm more used to.

I have a group of four other Linux systems (3 × Gentoo, 1 × Ubuntu) exchanging files perfectly, even when run as something other than the
uucp user. All systems, including macOS, are running Taylor UUCP. (No
known relation.)

Other than filesystem quirks (UUCP temp filenames or target filenames
might be case sensitive, which would cause a surprise when running
on HFS),

I know that file name case is not an issue. I assume that macOS
Catalina 10.15.15 is using HFS+.

or setting up a daemon via Launchd,

Everything is currently initiated on the macOS side. It does not allow
any externally initiated inbound connections, for various reasons.

So, my normal user calls uucp / uuto / uux, which in turn calls uucico,
which in turn may call uuxqt as necessary.

I don't think there are that many MacOS-specific issues that would
trip you up.

I had to berate macOS to get it to play nice, despite it coming from
Apple with macOS Catalina 10.15.15.

- I had to disable System Integrity Protection (a trip in and of itself).
- Remount root read-write so that I could edit the config files.
- chown uucp related binaries to _uucp:
- chmod uucp related binaries to setuid & setgid
- chmod permissions on the uucp spool directory
- create the uucp public directory

I'm using an ssh (STDIO) pipe (not port forwarding) between macOS and
one of the Linux systems. The ssh configuration works perfectly fine.
The _uucp user on macOS can log into the remote system without being
prompted for passwords. (SSH keys are wonderful. Especially when
forcing commands.)

I don't believe the SSH aspect is the root of the problem. Though it
may be related.

I think it's not the root of the problem because things work perfectly
when running uucico as the _uucp user.

Similarly, if I add "-r" to the uucp / uuto / uux commands run by the
non-_uucp user, so that they only spool their request and don't actually
start uucico and subsequently run uucico as the _uucp user, everything
works as expected. non-_uucp users files / commands get queued as
expected. uucico works as expected when run as _uucp.

I say that SSH /may/ be related because I do see the ssh pipe command
sequence when starting uucico as someone other than _uucp. But I think
that the ssh connection is working and that the problem is actually a
UUCP issue. I say this because uulog shows a connection and a
subsequent line error.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From somewhere in cyberspace, Grant Taylor <[email protected]> said: >On 6/30/20 9:42 AM, Ed Ravin wrote:

What problems are you running into?

Running uucico as anybody other than the _uucp user (Apple has
apparently renamed "uucp" to "_uucp") will end up with failed
connections, I believe related to a line error. Yet the exact same >configuration and uucico command work just fine when run as the _uucp
user. This may be related to what line / port type that I'm using; pipe
to ssh.

[...]

Similarly, if I add "-r" to the uucp / uuto / uux commands run by the >non-_uucp user, so that they only spool their request and don't actually >start uucico and subsequently run uucico as the _uucp user, everything
works as expected. non-_uucp users files / commands get queued as
expected. uucico works as expected when run as _uucp.

That's fascinating! The fact that everything works when the invocation
of ssh comes from the daemon but not when invoked by the user
suggests some kind of unwanted inheritance from the normal user's
environment. I wonder if it has to do with Keychain access or some
other Mac-specific hook in ssh.

Have you considered trying a different line/port type to see if that
gets rid of the problem? I suspect that stunnel, with client and server authentication enabled, would provide you with a similar level of
security and be easier to maintain.

Another possibility is to install a private version of ssh, either from Macports or build it yourself, and point UUCP to that binary.

- I had to disable System Integrity Protection (a trip in and of itself).
- Remount root read-write so that I could edit the config files.
- chown uucp related binaries to _uucp:
- chmod uucp related binaries to setuid & setgid
- chmod permissions on the uucp spool directory
- create the uucp public directory

You might be able to avoid all that by installing a private version of
uucp, like the one in MacPorts, which will use different paths and
shouldn't need any epic battles with the MacOS security settings.

If you'd rather debug the existing setup, try adding the "-v" option
to uucp's invocation of ssh and see what turns up in the logs. Add up to
two more "-v" options to increase verbosity. By comparing the log
output of a successful run with an unsuccessful one, you should get
some hints as to what's going wrong.

Good luck and let us know what happens!

-- Ed


--
Ed Ravin | Warning - this email may contain rhetorical
| devices, metaphors, analogies, typographical eravin@ | errors, or just plain snarkiness. A sense of panix.com | humor may be required for proper interpretation.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I got it working.

On 6/30/20 3:50 PM, Ed Ravin wrote:

That's fascinating! The fact that everything works when the invocation
of ssh comes from the daemon but not when invoked by the user suggests
some kind of unwanted inheritance from the normal user's environment.

Agreed.

I wonder if it has to do with Keychain access or some other
Mac-specific hook in ssh.

I don't think so.

Have you considered trying a different line/port type to see if
that gets rid of the problem?

I've thought about it, but have been disinclined to do so because the
same configuration is working on multiple Linux boxen. As such, I don't
think it's a line / port type, or UUCP configuration, problem.

I suspect that stunnel, with client and server authentication enabled,
would provide you with a similar level of security and be easier
to maintain.

I also have use for this with bastion hosts where only SSH is exposed,
and I'm loath to open another port. Especially for a configuration that
works correctly on multiple Linux boxen.

Another possibility is to install a private version of ssh, either
from Macports or build it yourself, and point UUCP to that binary.

You might be able to avoid all that by installing a private version
of uucp, like the one in MacPorts, which will use different paths
and shouldn't need any epic battles with the MacOS security settings.

I feel like that's over kill and would probably be a problem on one of
the systems I'm setting this up on.

The only epic nature of the battle was getting write access to the files
that needed to be updated. Once that was achieved, there was no more
battling.

I was also able to re-enable the System Integrity Protection and things
still work.

If you'd rather debug the existing setup, try adding the "-v" option
to uucp's invocation of ssh and see what turns up in the logs.

I did try that at one point. But the problem was the STDOUT from the
SSH process was not logged anywhere.

I ended up adding -E /path/to/log/file to the SSH command in addition to
the -v so that I could save the logs somewhere to look at them.

Add up to two more "-v" options to increase verbosity. By comparing
the log output of a successful run with an unsuccessful one, you
should get some hints as to what's going wrong.

Good luck and let us know what happens!

Ultimately I got things working.

I need to look at things and think about what was done between two
different macOS systems, Yosemite 10.10.5 & Catalina 10.15.15. Once I understand the differences between the two well enough to articulate,
I'll share my findings.

But, it's working.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/30/20 6:02 PM, Grant Taylor wrote:

I need to look at things and think about what was done between two
different macOS systems, Yosemite 10.10.5 & Catalina 10.15.15.  Once I understand the differences between the two well enough to articulate,
I'll share my findings.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)