[Info-vax] Need to set up a special purpose account

[Stephen Hoffman]

On 2016-10-10 15:42:51 +0000, Tom Adams said:

> I think a found the root of the problem.
> 
> There was an old SYS$SYSDEVICE:[TCPIP$FTP]TCPIP$FTP_ANONYMOUS.LOG
> file from 1995.  I don't know how it was created.  It might date
> back to UCX since some files somehow have alias names for UCX and
> TCPIP.
> 
> If I get rid of that file and then run tcpip$config.com to add the 
> optional anonymous tcpip, then it all works.
> 
> It's not a bug it's a feature.

FTP and the IP stack is a whole cascade of bugs and limitations and 
misfeatures and opportunities   In no particular order...

o FTP should not be easily available as it's insecure and there are 
better options, and should be far harder to locate.
o locking down FTP.   OpenVMS doesn't have capabilities similar to 
this, and relies on older and less flexible and more 
problematic-to-configure UIC- and privileges-based approaches.
o OpenVMS does not have a tradition of cleaning up old directories and 
old approaches, and the upgrade sequences — while functional — 
deliberately leave these messes around.
o the documentation did not get you where you needed to go.
o competitive systems have these features as little more than a single 
command or a GUI switch.
o FTP (and sftp, ftps, etc) should be available as dynamic volume 
mounts, though that's a client-related issue and rather less of a 
server-related issue,
o Much like VAX C, OpenVMS doesn't encourage and doesn't require folks 
to clean up the old messes.   It leaves folks to ignore these and other 
issues.   In cases such as this — and any other problematic or insecure 
cases — OpenVMS should flag objections to the system manager, 
preferably with a suggested migration.   Yes, there are specific cases 
where FTP makes sense, though I'd probably look to use HTTPS or sftp or 
FTPS even for those.   But setting up an FTP server is somewhat tricky 
in general, and keeping the server locked down tends to mean one-shot 
logins and write-only directories and other arcana and OpenVMS lacks 
that sort of support, and the documentation does nothing to help folks 
with these matters....

>   When you enable the ANONYMOUS TCPIP option, it does not create a new 
> TCPIP$FTP_ANONYMOUS.LOG, so if the one there is screwed up, then you 
> are screwed.

That's pretty typical with the TCP/IP Stack, unfortunately.   It gets 
badly tangled with directories and file ownerships, when they don't 
exactly match expectations.   There's also that UICs as implemented are 
very limiting, and that these various components should always exist 
and always with the same UIC and always in the same place — we aren't 
on VAX anymore, why write massively overly complex and — as shown in 
this and other cases — buggy code.

> 
> The file TCPIP$FTP_ANONYMOUS.LOG, when properly created, has an ACL 
> that gives [ANONY, ANONYMOUS] access.

Which is what would be expected, as that's how the anonymous user can 
write to the log.   Unfortunately, the anonymous user can also 
potentially clobber this file, which is because OpenVMS lacks a central 
logging mechanism which would keep these sorts of problems from being a 
concern.   If the log passes through an interface and into a different 
ownership, it's much easier to compartment the access.

Then there's the utter lack of IP stack integration, which is entirely 
lacking now, and apparently won't be addressed with VSI IP based on 
statements at the boot camp.

Good that you've got this working.   Change your passwords and your 
SYSTEM password (preferably not via telnet, for what should be obvious 
reasons), and expect any explicit logins into that FTP server to be 
compromised immediately.   This given you've exposed the name of the 
particular server apparently involved, too.  No, I'm not going to see 
if it's reachable.

TL;DR: the OpenVMS IP stack management is problematic — many good ideas 
and reasonable choices and trade-offs, which have unfortunately 
accreted into a serious mess  — and which should be vastly simpler to 
configure, manage and upgrade.



-- 
Pure Personal Opinion | HoffmanLabs LLC