Groups | Search | Server Info | Login | Register


Groups > comp.mail.uucp > #115

Re: macOS

From eravin@panix.com (Ed Ravin)
Newsgroups comp.mail.uucp
Subject Re: macOS
Date 2020-06-30 21:50 +0000
Organization All Watched Over by Machines of Loving Grace
Message-ID <rdgc3q$7bj$1@reader1.panix.com> (permalink)
References <rdben3$iem$1@tncsrv09.home.tnetconsulting.net> <rdfmhj$a21$1@reader1.panix.com> <rdfun5$20i$1@tncsrv09.home.tnetconsulting.net>

Show all headers | View raw


From somewhere in cyberspace, Grant Taylor <gtaylor@tnetconsulting.net> 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.

Back to comp.mail.uucp | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

macOS Grant Taylor <gtaylor@tnetconsulting.net> - 2020-06-28 19:04 -0600
  Re: macOS eravin@panix.com (Ed Ravin) - 2020-06-30 15:42 +0000
    Re: macOS Grant Taylor <gtaylor@tnetconsulting.net> - 2020-06-30 12:01 -0600
      Re: macOS eravin@panix.com (Ed Ravin) - 2020-06-30 21:50 +0000
        Re: macOS Grant Taylor <gtaylor@tnetconsulting.net> - 2020-06-30 18:02 -0600
          Re: macOS Grant Taylor <gtaylor@tnetconsulting.net> - 2020-06-30 18:46 -0600

csiph-web