Discussion:
Unexpected DECnet Phase IV functionality with possible captive account implications
Add Reply
Simon Clubley
2021-05-10 18:20:15 UTC
Reply
Permalink
I have come across some very unexpected DECnet Phase IV functionality
while I was looking at the FAL specification.

Did you know that you can directly submit batch jobs using FAL from
across the network without having to go anywhere near a command prompt
on the target system ? The command procedure runs on SYS$BATCH on
the target system as the user you have logged into with FAL on the
target system.

Did you also know that this functionality works just fine with captive
accounts so you can transfer a command procedure containing commands
of your choice to a captive account using FAL (assuming network access
is not explicitly blocked) and then submit it for execution ?

The other major surprise I had was that task-to-task communications
works just fine (assuming once again network access is not explicitly
blocked) when the target is a command procedure in a captive account,
so you can transfer a command procedure using FAL and execute it in
that way as well.

Also note that if your login command procedure for the captive account
is poorly written so that it falls through without doing an explicit
logout (IOW, if you get the captive account - interactive access denied
message when the login command procedure has finished) then you can
get into network mode in that way as well if you don't do an explicit
check for network mode.

I spoke to VSI about this before posting this because of the possible
security implications but they don't see a problem with this. I disagree.

FAL is supposed to be a data transfer mechanism only and even the
40-year-old FAL specification states that a FAL implementation should
not be used for anything other than just transferring files.

Task-to-task communications should also be disabled by default for
captive accounts IMHO. There should be some setting somewhere that
you need to turn on explicitly for captive accounts if you want the
active features of DECnet such as remote batch job submission and
task-to-task communications.

VMS was sold as being secure out of the box and that you have to know
enough about VMS to make it insecure. You shouldn't have to work the
other way around and start pulling bits of clues from the documentation
about how to make potentially insecure settings secure.

I only found out about this when I came across the comments in the
FAL specification about the supposedly obsolete batch submission
capability and I started looking closer. I wonder how many other
people don't know about this.

And finally, a question: Assume that your captive account needs network
access because it is a dropbox style account where files are transferred
to it over the network with FAL and then the user logs into the captive
account from a terminal session to review and then process the files.

How would you setup the captive account so that the passive features
of DECnet would work (such as file transfer using FAL) but the active
features (remote batch job submission and task-to-task communications)
would be disabled, but ideally only disabled for that captive account ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Stephen Hoffman
2021-05-10 18:45:35 UTC
Reply
Permalink
Post by Simon Clubley
I have come across some very unexpected DECnet Phase IV functionality
while I was looking at the FAL specification.
Did you know that you can directly submit batch jobs using FAL from
across the network without having to go anywhere near a command prompt
on the target system ? The command procedure runs on SYS$BATCH on the
target system as the user you have logged into with FAL on the target
system.
See the SUBMIT /REMOTE command.
Post by Simon Clubley
Did you also know that this functionality works just fine with captive
accounts so you can transfer a command procedure containing commands of
your choice to a captive account using FAL (assuming network access is
not explicitly blocked) and then submit it for execution ?
The accounts have to be marked NOBATCH or NONETWORK or NOOTHER, or that
access otherwise blocked by the DCL procedures.
Post by Simon Clubley
The other major surprise I had was that task-to-task communications
works just fine (assuming once again network access is not explicitly
blocked) when the target is a command procedure in a captive account,
so you can transfer a command procedure using FAL and execute it in
that way as well.
If the DCL is present to and readable by the captive user, it can be
involved, yes. Best to use execute-only access, though I'd not presume
that to be entirely secure either.
Post by Simon Clubley
Also note that if your login command procedure for the captive account
is poorly written so that it falls through without doing an explicit
logout (IOW, if you get the captive account - interactive access denied
message when the login command procedure has finished) then you can get
into network mode in that way as well if you don't do an explicit check
for network mode.
Problems with error-handling doom a whole lot of software.
Post by Simon Clubley
I spoke to VSI about this before posting this because of the possible
security implications but they don't see a problem with this. I disagree.
Captive doesn't get to write anywhere outside of very targeted
directories, and then only with constraints. See below for more on the
constraints.
Post by Simon Clubley
And finally, a question: Assume that your captive account needs network
access because it is a dropbox style account where files are
transferred to it over the network with FAL and then the user logs into
the captive account from a terminal session to review and then process
the files.
ssh has a similar mess waiting, here. That requires added configuration
work to disable sftp.

If the account is an FTP or SFTP or FAL drop-box, it CANNOT be allowed
to set the filename, and the processing MUST move the file away from
the dropbox directory, and the user CANNOT be allowed to access the
uploaded file absent additional processing. (q.v. gifar, for a very
old example of this mess. Writing a secure dropbox app is not trivial.)
Post by Simon Clubley
How would you setup the captive account so that the passive features of
DECnet would work (such as file transfer using FAL) but the active
features (remote batch job submission and task-to-task communications)
would be disabled, but ideally only disabled for that captive account ?
I don't let folks log into the server if I can avoid it. If I can't
avoid that, then the login is locked down, with ACLs to keep access
further constrained, and subsystem identifiers to constrain what the
captive user can access. This is a form of home-grown sand-boxing,
which isn't all that effective, and isn't all that well documented.

Credential-based and proxy-based DECnet logins and FTP logins are not
something I'd rely upon to remain secure, either.

And there's a reason I keep writing comments about the problems of
continued use of DECnet...
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2021-05-10 19:38:40 UTC
Reply
Permalink
Post by Stephen Hoffman
Captive doesn't get to write anywhere outside of very targeted
directories, and then only with constraints. See below for more on the
constraints.
Captive accounts can be privileged. In fact, that's the whole point
of them for a good range of usage cases.
Post by Stephen Hoffman
And there's a reason I keep writing comments about the problems of
continued use of DECnet...
Well, I can now say that the FAL protocol is one of the most ugly
designs I have seen. It's the type of protocol that only an assembly
language programmer could think was elegant. :-)

The design is full of optional fields and bitfields listing which
fields are present. This has to be examined before looking for each
of the remaining (possibly omitted) fields and this has to be done
for every field in the FAL messages which implement this.

NSP isn't much better with messages that may or may not have one
or both ACK fields and you tell this by looking to see if the top
bit of the next 16-bit word is set.

I find that amusing given the amount of redundancy you have in the
routing layer part of a DECnet Ethernet packet.

These are protocols that were designed in _very_ different times...

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
David Jones
2021-05-10 20:22:42 UTC
Reply
Permalink
Post by Simon Clubley
Well, I can now say that the FAL protocol is one of the most ugly
designs I have seen. It's the type of protocol that only an assembly
language programmer could think was elegant. :-)
It was designed when the link layer was DDCMP and every bit counted.
Stephen Hoffman
2021-05-10 21:07:49 UTC
Reply
Permalink
Post by Stephen Hoffman
Captive doesn't get to write anywhere outside of very targeted
directories, and then only with constraints. See below for more on the
constraints.
Captive accounts can be privileged. In fact, that's the whole point of
them for a good range of usage cases.
In recent years, I prefer the CAPTIVE users be set up minimally privileged.

That means probably TMPMBX, maybe NETMBX.

How? I've become fond of using subsystem identifiers and executable
images, and of using privileged server processes.

The privileged server process might as simplistic as some DCL or other
scripting or other application on the far end of a host-local DECnet
connection, or on the far end of a mailbox, or some other other
interprocess communications.

DCL interprocess communications support is seriously lacking, but
that's fodder for another discussion or three.

This approach keeps the privileges somewhat less accessible to the users.

Again, this is basic app sandboxing, albeit a less-than-well-documented
topic on OpenVMS, and with minimal OpenVMS support past the classic
here's-a-box-of-parts-have-at stage.
Post by Stephen Hoffman
And there's a reason I keep writing comments about the problems of
continued use of DECnet...
Well, I can now say that the FAL protocol is one of the most ugly
designs I have seen...
There are lots of ugly protocols in this business. I've created a few
ugly protocols myself.

Stupidly forgot to embed protocol version info in one of my earliest
designs. But I digress.

Ugly protocols may or may not have ugly parsers. But I don't trust parsers.

Got a lot on that best-to-distrust-a-parser topic too, and here's just a taste:
https://blog.trailofbits.com/2019/11/01/two-new-tools-that-tame-the-treachery-of-files/

https://googleprojectzero.blogspot.com/2021/01/a-look-at-imessage-in-ios-14.html
These are protocols that were designed in _very_ different times...
That DECnet is "~unauthenticated" and "unencrypted" tends to be a
bigger concern for many, whether they realize it yet or not.

I'd prefer that DECnet, FTP, telnet, and ilk, all be removed from the
base distro, and made separately installable. With caveats.

Are there CAPTIVE logins around which can be exploited? I'd expect so.
I had great fun exploiting with those using the INQUIRE command, until
that hole got plugged.
--
Pure Personal Opinion | HoffmanLabs LLC
Some Dude
2021-05-10 19:27:40 UTC
Reply
Permalink
Post by Simon Clubley
I have come across some very unexpected DECnet Phase IV functionality
while I was looking at the FAL specification.
Did you know that you can directly submit batch jobs using FAL from
across the network without having to go anywhere near a command prompt
on the target system ? The command procedure runs on SYS$BATCH on
the target system as the user you have logged into with FAL on the
target system.
What Simon omits is that you are required to provide login credentials (absent a default FAL
account which would leave your system vulnerable to many more interesting things.)

The response from VSI also included:

As such, outside the inherent security problems with the unencrypted DECnet transport
itself...

-----
Post by Simon Clubley
And there's a reason I keep writing comments about the problems of
continued use of DECnet...
--Doug
Simon Clubley
2021-05-10 19:47:16 UTC
Reply
Permalink
Post by Some Dude
Post by Simon Clubley
I have come across some very unexpected DECnet Phase IV functionality
while I was looking at the FAL specification.
Did you know that you can directly submit batch jobs using FAL from
across the network without having to go anywhere near a command prompt
on the target system ? The command procedure runs on SYS$BATCH on
the target system as the user you have logged into with FAL on the
target system.
What Simon omits is that you are required to provide login credentials (absent a default FAL
account which would leave your system vulnerable to many more interesting things.)
Er, Doug, that is implicit in how FAL and task-to-task communications
work. Just because someone thought that adding a feature to a protocol
or making it enabled by default was a good idea, doesn't mean that it
is, especially these days.

The whole point of running this by VSI first was that I found the
presence of this functionality to be very surprising, especially given
that the FAL specification says implementations should not have such
functionality.

It might also be surprising to someone setting up a DECnet network
that wasn't aware of these little extra features, especially given
how they relate to captive accounts.
Post by Some Dude
As such, outside the inherent security problems with the unencrypted DECnet transport
itself...
I wonder if this works over one of the DECnet to TCP/IP protocols ?

Unfortunately, I don't have the setup to test that out.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Michael Moroney
2021-05-10 22:08:35 UTC
Reply
Permalink
Post by Simon Clubley
I have come across some very unexpected DECnet Phase IV functionality
while I was looking at the FAL specification.
Did you know that you can directly submit batch jobs using FAL from
across the network without having to go anywhere near a command prompt
on the target system ? The command procedure runs on SYS$BATCH on
the target system as the user you have logged into with FAL on the
target system.
More like an RMS feature, something which piggybacks on RMS $CLOSE. If
you set the magic bit, the file gets submitted/printed when closed.

$ SUBMIT/REMOTE takes advantage of this, as does DCL $ CLOSE/DISPOSITION
Dave Froble
2021-05-10 22:13:53 UTC
Reply
Permalink
Post by Simon Clubley
I have come across some very unexpected DECnet Phase IV functionality
while I was looking at the FAL specification.
DECnet IV is rather old, but has been useful for a long time.
Post by Simon Clubley
Did you know that you can directly submit batch jobs using FAL from
across the network without having to go anywhere near a command prompt
on the target system ? The command procedure runs on SYS$BATCH on
the target system as the user you have logged into with FAL on the
target system.
Ok, what is the problem with this? One still has to be a valid user on
the remote system. What's the difference between logging onto the
remote system and submitting the job?

FAL is a very useful tool.
Post by Simon Clubley
Did you also know that this functionality works just fine with captive
accounts so you can transfer a command procedure containing commands
of your choice to a captive account using FAL (assuming network access
is not explicitly blocked) and then submit it for execution ?
If you are logged into a captive account, you can only do what the
command file for the captive account is set up to do. I'd guess any
issues would lie in the domain of the people setting up the captive
account command file, not DECnet.
Post by Simon Clubley
The other major surprise I had was that task-to-task communications
works just fine (assuming once again network access is not explicitly
blocked) when the target is a command procedure in a captive account,
so you can transfer a command procedure using FAL and execute it in
that way as well.
See above about captive account command procedure.
Post by Simon Clubley
Also note that if your login command procedure for the captive account
is poorly written so that it falls through without doing an explicit
logout (IOW, if you get the captive account - interactive access denied
message when the login command procedure has finished) then you can
get into network mode in that way as well if you don't do an explicit
check for network mode.
I spoke to VSI about this before posting this because of the possible
security implications but they don't see a problem with this. I disagree.
I do not see a problem.
Post by Simon Clubley
FAL is supposed to be a data transfer mechanism only and even the
40-year-old FAL specification states that a FAL implementation should
not be used for anything other than just transferring files.
Opinion or fact? FAL is very useful. FAL can be used for accessing
files, not just transferring files.
Post by Simon Clubley
Task-to-task communications should also be disabled by default for
captive accounts IMHO. There should be some setting somewhere that
you need to turn on explicitly for captive accounts if you want the
active features of DECnet such as remote batch job submission and
task-to-task communications.
That is the responsibility of the system manager.
Post by Simon Clubley
VMS was sold as being secure out of the box and that you have to know
enough about VMS to make it insecure. You shouldn't have to work the
other way around and start pulling bits of clues from the documentation
about how to make potentially insecure settings secure.
VMS is not shipped with any captive accounts set up.
Post by Simon Clubley
I only found out about this when I came across the comments in the
FAL specification about the supposedly obsolete batch submission
capability and I started looking closer. I wonder how many other
people don't know about this.
And finally, a question: Assume that your captive account needs network
access because it is a dropbox style account where files are transferred
to it over the network with FAL and then the user logs into the captive
account from a terminal session to review and then process the files.
How would you setup the captive account so that the passive features
of DECnet would work (such as file transfer using FAL) but the active
features (remote batch job submission and task-to-task communications)
would be disabled, but ideally only disabled for that captive account ?
Simon.
Bottom line, DECnet IV was implemented in an earlier time, to solve
problems from that time. Yes, no encryption, no concerns about security
as it's practiced (if at all) today. Judge it on then, not now.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-05-11 13:08:21 UTC
Reply
Permalink
Post by Dave Froble
Post by Simon Clubley
Did you know that you can directly submit batch jobs using FAL from
across the network without having to go anywhere near a command prompt
on the target system ? The command procedure runs on SYS$BATCH on
the target system as the user you have logged into with FAL on the
target system.
Ok, what is the problem with this? One still has to be a valid user on
the remote system. What's the difference between logging onto the
remote system and submitting the job?
If it's an interactive account where you can get to the DCL prompt, then
nothing. If it's a captive account, then a lot.
Post by Dave Froble
FAL is a very useful tool.
Post by Simon Clubley
Did you also know that this functionality works just fine with captive
accounts so you can transfer a command procedure containing commands
of your choice to a captive account using FAL (assuming network access
is not explicitly blocked) and then submit it for execution ?
If you are logged into a captive account, you can only do what the
command file for the captive account is set up to do. I'd guess any
issues would lie in the domain of the people setting up the captive
account command file, not DECnet.
You have completely and totally missed the whole point of my original posting.

Due to unexpected functionality, if you can get to the captive account
via a network login, you can directly execute any DCL commands you choose
regardless of whatever the login command procedure does in terms of
interactive user input when you login from a terminal session.
Post by Dave Froble
Post by Simon Clubley
The other major surprise I had was that task-to-task communications
works just fine (assuming once again network access is not explicitly
blocked) when the target is a command procedure in a captive account,
so you can transfer a command procedure using FAL and execute it in
that way as well.
See above about captive account command procedure.
See above about totally missing the point I was making.
Post by Dave Froble
Post by Simon Clubley
Also note that if your login command procedure for the captive account
is poorly written so that it falls through without doing an explicit
logout (IOW, if you get the captive account - interactive access denied
message when the login command procedure has finished) then you can
get into network mode in that way as well if you don't do an explicit
check for network mode.
I spoke to VSI about this before posting this because of the possible
security implications but they don't see a problem with this. I disagree.
I do not see a problem.
Then you have missed the point of what I am saying.
Post by Dave Froble
Post by Simon Clubley
FAL is supposed to be a data transfer mechanism only and even the
40-year-old FAL specification states that a FAL implementation should
not be used for anything other than just transferring files.
Opinion or fact? FAL is very useful. FAL can be used for accessing
files, not just transferring files.
Fact, if you change "transfer" to "access" in my wording. It's in the
FAL specification that a FAL implementation should only implement passive
data access and not do anything active such as remote job entry.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-05-11 14:42:41 UTC
Reply
Permalink
Post by Simon Clubley
Post by Dave Froble
Post by Simon Clubley
Did you know that you can directly submit batch jobs using FAL from
across the network without having to go anywhere near a command prompt
on the target system ? The command procedure runs on SYS$BATCH on
the target system as the user you have logged into with FAL on the
target system.
Ok, what is the problem with this? One still has to be a valid user on
the remote system. What's the difference between logging onto the
remote system and submitting the job?
If it's an interactive account where you can get to the DCL prompt, then
nothing. If it's a captive account, then a lot.
Access to the remote system is defined by system manager(s). If
allowed, then no problem. If not allowed, then no user account, and
again no problem.
Post by Simon Clubley
Post by Dave Froble
FAL is a very useful tool.
Post by Simon Clubley
Did you also know that this functionality works just fine with captive
accounts so you can transfer a command procedure containing commands
of your choice to a captive account using FAL (assuming network access
is not explicitly blocked) and then submit it for execution ?
If you are logged into a captive account, you can only do what the
command file for the captive account is set up to do. I'd guess any
issues would lie in the domain of the people setting up the captive
account command file, not DECnet.
You have completely and totally missed the whole point of my original posting.
I did not miss your point. What you have decided to ignore is the
requirement for system management of user access. VMS of 30+ years ago
requires system management. It does not assume automatic security. Do
remember, the distribution shipped with the password of the SYSTEM user
account as MANAGER. No problem, if the system access was managed. Yes,
a problem, if such access was not properly managed.
Post by Simon Clubley
Due to unexpected functionality, if you can get to the captive account
via a network login, you can directly execute any DCL commands you choose
regardless of whatever the login command procedure does in terms of
interactive user input when you login from a terminal session.
Not "unexpected functionality".

A captive user, unless set up to do so, cannot create any command files.
So no choices available.
Post by Simon Clubley
Post by Dave Froble
Post by Simon Clubley
The other major surprise I had was that task-to-task communications
works just fine (assuming once again network access is not explicitly
blocked) when the target is a command procedure in a captive account,
so you can transfer a command procedure using FAL and execute it in
that way as well.
See above about captive account command procedure.
See above about totally missing the point I was making.
Post by Dave Froble
Post by Simon Clubley
Also note that if your login command procedure for the captive account
is poorly written so that it falls through without doing an explicit
logout (IOW, if you get the captive account - interactive access denied
message when the login command procedure has finished) then you can
get into network mode in that way as well if you don't do an explicit
check for network mode.
I spoke to VSI about this before posting this because of the possible
security implications but they don't see a problem with this. I disagree.
I do not see a problem.
Then you have missed the point of what I am saying.
Post by Dave Froble
Post by Simon Clubley
FAL is supposed to be a data transfer mechanism only and even the
40-year-old FAL specification states that a FAL implementation should
not be used for anything other than just transferring files.
Opinion or fact? FAL is very useful. FAL can be used for accessing
files, not just transferring files.
Fact, if you change "transfer" to "access" in my wording. It's in the
FAL specification that a FAL implementation should only implement passive
data access and not do anything active such as remote job entry.
You have chosen to ignore the fact that setting up of the captive user
capabilities either controls all issues, or, it might as well not have
been a captive user account.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-05-11 17:34:27 UTC
Reply
Permalink
Post by Dave Froble
Post by Simon Clubley
Due to unexpected functionality, if you can get to the captive account
via a network login, you can directly execute any DCL commands you choose
regardless of whatever the login command procedure does in terms of
interactive user input when you login from a terminal session.
Not "unexpected functionality".
A captive user, unless set up to do so, cannot create any command files.
So no choices available.
You cannot protect against something you didn't know about or when the
security implications of that something were not explained well enough
in the manuals.

I only found out about the remote batch submission capability after
reading the FAL specification recently and that's from someone who
has been actively discussing security issues in VMS for a number of years.

BTW, does anyone know if there are similar submit on close or submit
on transfer complete functions in the implementation of the other VMS
communication protocols that would work just fine with captive accounts ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Jan-Erik Söderholm
2021-05-11 22:01:10 UTC
Reply
Permalink
Post by Simon Clubley
Post by Dave Froble
Post by Simon Clubley
Due to unexpected functionality, if you can get to the captive account
via a network login, you can directly execute any DCL commands you choose
regardless of whatever the login command procedure does in terms of
interactive user input when you login from a terminal session.
Not "unexpected functionality".
A captive user, unless set up to do so, cannot create any command files.
So no choices available.
You cannot protect against something you didn't know about or when the
security implications of that something were not explained well enough
in the manuals.
I only found out about the remote batch submission capability after
reading the FAL specification recently and that's from someone who
has been actively discussing security issues in VMS for a number of years.
BTW, does anyone know if there are similar submit on close or submit
on transfer complete functions in the implementation of the other VMS
communication protocols that would work just fine with captive accounts ?
I haven't look closely, but when doing a FTP to on MVS system, you could
specify the outpout file as "INTRDR". That is the "internal card reader"
and sending anything to that "file" would submit a MVS batch job.
And this was over standard FTP.

I do not know if there exist some similar "batch spooling" feature
when FTP'ing a file to VMS...
Post by Simon Clubley
Simon.
Simon Clubley
2021-05-12 12:26:00 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
I haven't look closely, but when doing a FTP to on MVS system, you could
specify the outpout file as "INTRDR". That is the "internal card reader"
and sending anything to that "file" would submit a MVS batch job.
And this was over standard FTP.
Thank you Jan-Erik, I wasn't aware of that.
Post by Jan-Erik Söderholm
I do not know if there exist some similar "batch spooling" feature
when FTP'ing a file to VMS...
I've just had a quick look at the Multinet FTP client help but I don't
see anything obvious that implements this functionality there.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Mark Berryman
2021-05-12 17:35:32 UTC
Reply
Permalink
Post by Simon Clubley
.
.
I only found out about the remote batch submission capability after
reading the FAL specification recently and that's from someone who
has been actively discussing security issues in VMS for a number of years.
.
.
.
<facepalm>

If this is how you found out about it then I have to assume there are a
number of manuals you haven't read since remote batch submission is both
known and documented.

I am also guessing that you have never been responsible for maintaining
a captive account, or that you've read the various sections in the
manuals you should read when setting one up. In particular, you might
want to pay attention to this line:

"Accounts under which network objects run, for example, require
temporary access to DCL. "

To test, I set up a captive account WITHOUT any of the protections
normally associated with a captive account. For example, with rare
exception, almost any captive account login procedure is going to have a
line similar to the following near the top:

$ if f$mode() .nes. "INTERACTIVE" then logout

But let's skip that. Let's pretend this account was set up by someone
who didn't read the manuals.

This captive account simply runs a menu. When the menu exits, the
account exits. Fortunately, VMS provides us with a nice menu to test
with. Here are the contents of the captive account's login procedure:

$ @ssl111$com:ssl111$cert_tool.com
$ logout

No sanity or security checks of any kind. Just call the menu and logout
when done. Now, let's use DECnet to copy a file into the captive
account so we can do something nefarious:

$ copy tmp.tmp aldur1"james password"::
%COPY-E-OPENOUT, error opening ALDUR1"james password"::[]tmp.tmp;1 as output
-RMS-E-CRE, ACP file create failed
-SYSTEM-F-LINKEXIT, network partner exited
%COPY-W-NOTCOPIED, USERS:[BERRYMAN]tmp.tmp;1 not copied

Oh dear, the copy failed. I wonder why. Let's check the netserver.log
file to find out. It turns out that network jobs happen to run the
captive account's login procedure, which was a menu, which didn't
understand what FAL was sending, so it retried a few times (several,
actually) until it gave up and quit.

So let's simulate having some way to bypass that menu. I've changed the
login procedure to the following:

$ if f$mode() .eqs. "INTERACTIVE" then @ssl111$com:ssl111$cert_tool.com
$ logout

Same result, the copy fails. So does $ SUBNET/REMOTE

In practice, Captive accounts will typically have quite a few sanity and
security checks in them. F$MODE checks in the login procedure, NOBATCH,
NONETWORK, etc. in the UAF settings, lack of NETMBX privs, etc. Any or
all of these will prevent what you are trying to do.

So, tempest in a teapot anyone?

Mark Berryman
Simon Clubley
2021-05-12 17:40:09 UTC
Reply
Permalink
Post by Mark Berryman
So, tempest in a teapot anyone?
Maybe. Maybe not. I suppose it depends on how you are looking at it.

It was just a major surprise to me when I found out about it and
that the functionality was enabled by default.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Stephen Hoffman
2021-05-11 14:44:10 UTC
Reply
Permalink
Post by Dave Froble
Post by Simon Clubley
I have come across some very unexpected DECnet Phase IV functionality
while I was looking at the FAL specification.
DECnet IV is rather old, but has been useful for a long time.
Today is a good day to consider alternatives to DECnet, too.
Post by Dave Froble
Post by Simon Clubley
Did you know that you can directly submit batch jobs using FAL from
across the network without having to go anywhere near a command prompt
on the target system ? The command procedure runs on SYS$BATCH on the
target system as the user you have logged into with FAL on the target
system.
Ok, what is the problem with this? One still has to be a valid user on
the remote system. What's the difference between logging onto the
remote system and submitting the job?
If the CAPTIVE user doesn't authenticate past the username, or has a
known password or, you know, it's DECnet so anybody with an interest in
the credentials probably already knows the credentials or should be
assumed to know, so, access is available.

And the detail I'm going to have to ponder now—for those cases where
DECnet is still lit—is whether some component of the CAPTIVE command
procedure environment might be triggered out-of-band. And what might
happen.

This when a CAPTIVE environment is built from multiple command procedures.

If the main procedure enforces access for invoking some "nested"
command procedure, I hadn't given much consideration to that "nested"
procedure being triggered (submitted) directly, rather than via the
main procedure.

NONETWORK is probably goodness. NOOTHER (err, no detached jobs
permitted) and NOBATCH may or may not be possible with some CAPTIVE
procedures, absent privilege separation and inter-process
communications with privileged server processes for those that use
detached or batch jobs. Or, you know, maybe even actual process
management and scheduling support.
Post by Dave Froble
FAL is a very useful tool.
sftp, scp, and ssh, too.
Post by Dave Froble
If you are logged into a captive account, you can only do what the
command file for the captive account is set up to do. I'd guess any
issues would lie in the domain of the people setting up the captive
account command file, not DECnet.
It's a way of directly activating hunks of a captive environment that
might not be accessible directly.
Post by Dave Froble
Post by Simon Clubley
The other major surprise I had was that task-to-task communications
works just fine (assuming once again network access is not explicitly
blocked) when the target is a command procedure in a captive account,
so you can transfer a command procedure using FAL and execute it in
that way as well.
See above about captive account command procedure.
See above above directly accessing and submitting hunks of the CAPTIVE
environment.
Post by Dave Froble
Post by Simon Clubley
Also note that if your login command procedure for the captive account
is poorly written so that it falls through without doing an explicit
logout (IOW, if you get the captive account - interactive access denied
message when the login command procedure has finished) then you can get
into network mode in that way as well if you don't do an explicit check
for network mode.
...
Post by Simon Clubley
FAL is supposed to be a data transfer mechanism only and even the
40-year-old FAL specification states that a FAL implementation should
not be used for anything other than just transferring files.
Opinion or fact? FAL is very useful. FAL can be used for accessing
files, not just transferring files.
sftp and scp and ssh are very useful, too.

There are things I'd like to see with sfpd yes, but most of the time I
can or do have a window open "over there" and have direct access.
Post by Dave Froble
Post by Simon Clubley
Task-to-task communications should also be disabled by default for
captive accounts IMHO. There should be some setting somewhere that you
need to turn on explicitly for captive accounts if you want the active
features of DECnet such as remote batch job submission and task-to-task
communications.
That is the responsibility of the system manager.
Nah, it's pretty much on the app authors; on the developers. Who set up
the CAPTIVE environments. Who increasingly either create the CAPTIVE
usernames, or write the directions for the CAPTIVE user creation. App
developers that are often focused elsewhere, and can sometimes miss or
can ignore security issues. Hopefully the system managers catch these
mistakes, but that still means some number of the developer's sites are
potentially open to problems.

This ties back into my longstanding comments about making DECnet
installation and configuration incrementally more involved too; of
explicitly flagging the risks to the app developers and system
management folks; of defaulting to secure installs.

You want or need to use DECnet, telnet, FTP or ilk, you get a few added
steps to install and configure and start those, and the manager or the
developer gets to acknowledge and read and override the warnings.
Post by Dave Froble
Bottom line, DECnet IV was implemented in an earlier time, to solve
problems from that time. Yes, no encryption, no concerns about
security as it's practiced (if at all) today. Judge it on then, not
now.
If DECnet is in use today—outside of a museum or a hobbyist—it's a
target for attack today, and it gets judged by today, and not by then.
--
Pure Personal Opinion | HoffmanLabs LLC
Dave Froble
2021-05-11 18:30:01 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by Dave Froble
Post by Simon Clubley
I have come across some very unexpected DECnet Phase IV functionality
while I was looking at the FAL specification.
DECnet IV is rather old, but has been useful for a long time.
Today is a good day to consider alternatives to DECnet, too.
For some things, yes. Some capabilities exist only in DECnet.
Post by Stephen Hoffman
Post by Dave Froble
Post by Simon Clubley
Did you know that you can directly submit batch jobs using FAL from
across the network without having to go anywhere near a command
prompt on the target system ? The command procedure runs on SYS$BATCH
on the target system as the user you have logged into with FAL on the
target system.
Ok, what is the problem with this? One still has to be a valid user
on the remote system. What's the difference between logging onto the
remote system and submitting the job?
If the CAPTIVE user doesn't authenticate past the username, or has a
known password or, you know, it's DECnet so anybody with an interest in
the credentials probably already knows the credentials or should be
assumed to know, so, access is available.
And the detail I'm going to have to ponder now—for those cases where
DECnet is still lit—is whether some component of the CAPTIVE command
procedure environment might be triggered out-of-band. And what might
happen.
This when a CAPTIVE environment is built from multiple command procedures.
I do not do that.
Post by Stephen Hoffman
If the main procedure enforces access for invoking some "nested" command
procedure, I hadn't given much consideration to that "nested" procedure
being triggered (submitted) directly, rather than via the main procedure.
NONETWORK is probably goodness. NOOTHER (err, no detached jobs
permitted) and NOBATCH may or may not be possible with some CAPTIVE
procedures, absent privilege separation and inter-process communications
with privileged server processes for those that use detached or batch
jobs. Or, you know, maybe even actual process management and scheduling
support.
Post by Dave Froble
FAL is a very useful tool.
sftp, scp, and ssh, too.
Which of them allow:

Open "DFE90A::[DFE]DATA.DAT" For Input as File #1%

Assuming proxys are set appropriately.

Please don't reply with:

Open "DFE90A"DFE XXX"::[DFE]DATA.DAT" For Input as File #1%

If I even remember how to do that correctly ...
Post by Stephen Hoffman
Post by Dave Froble
If you are logged into a captive account, you can only do what the
command file for the captive account is set up to do. I'd guess any
issues would lie in the domain of the people setting up the captive
account command file, not DECnet.
It's a way of directly activating hunks of a captive environment that
might not be accessible directly.
Only if those "hunks" exist.
Post by Stephen Hoffman
Post by Dave Froble
Post by Simon Clubley
The other major surprise I had was that task-to-task communications
works just fine (assuming once again network access is not explicitly
blocked) when the target is a command procedure in a captive account,
so you can transfer a command procedure using FAL and execute it in
that way as well.
See above about captive account command procedure.
See above above directly accessing and submitting hunks of the CAPTIVE
environment.
Post by Dave Froble
Post by Simon Clubley
Also note that if your login command procedure for the captive
account is poorly written so that it falls through without doing an
explicit logout (IOW, if you get the captive account - interactive
access denied message when the login command procedure has finished)
then you can get into network mode in that way as well if you don't
do an explicit check for network mode.
...
Post by Simon Clubley
FAL is supposed to be a data transfer mechanism only and even the
40-year-old FAL specification states that a FAL implementation should
not be used for anything other than just transferring files.
Opinion or fact? FAL is very useful. FAL can be used for accessing
files, not just transferring files.
sftp and scp and ssh are very useful, too.
There are things I'd like to see with sfpd yes, but most of the time I
can or do have a window open "over there" and have direct access.
As do I ...
Post by Stephen Hoffman
Post by Dave Froble
Post by Simon Clubley
Task-to-task communications should also be disabled by default for
captive accounts IMHO. There should be some setting somewhere that
you need to turn on explicitly for captive accounts if you want the
active features of DECnet such as remote batch job submission and
task-to-task communications.
That is the responsibility of the system manager.
Nah, it's pretty much on the app authors; on the developers. Who set up
the CAPTIVE environments. Who increasingly either create the CAPTIVE
usernames, or write the directions for the CAPTIVE user creation. App
developers that are often focused elsewhere, and can sometimes miss or
can ignore security issues. Hopefully the system managers catch these
mistakes, but that still means some number of the developer's sites are
potentially open to problems.
Not this app author ...
Post by Stephen Hoffman
This ties back into my longstanding comments about making DECnet
installation and configuration incrementally more involved too; of
explicitly flagging the risks to the app developers and system
management folks; of defaulting to secure installs.
You want or need to use DECnet, telnet, FTP or ilk, you get a few added
steps to install and configure and start those, and the manager or the
developer gets to acknowledge and read and override the warnings.
I can agree with this. No bother at all. Doing so might also cause
system management to evaluate how DECnet can be used.
Post by Stephen Hoffman
Post by Dave Froble
Bottom line, DECnet IV was implemented in an earlier time, to solve
problems from that time. Yes, no encryption, no concerns about
security as it's practiced (if at all) today. Judge it on then, not now.
If DECnet is in use today—outside of a museum or a hobbyist—it's a
target for attack today, and it gets judged by today, and not by then.
Judged for use today, yes, the original development should not be judged
by today, unless a time machine was available to the developers.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Stephen Hoffman
2021-05-11 20:57:30 UTC
Reply
Permalink
Post by Dave Froble
Open "DFE90A::[DFE]DATA.DAT" For Input as File #1%
Assuming proxys are set appropriately.
Open "DFE90A"DFE XXX"::[DFE]DATA.DAT" For Input as File #1%
If I even remember how to do that correctly ...
What you're doing with RMS and FAL is entirely feasible, though through
different means.

MOUNT the remote system, and access it locally. With newer systems,
that'd usually be an SMB mount, though OpenVMS lacks modern storage
connections. On OpenVMS, it'd be NFS, or maybe DFS. Then aim SQLite at
it, etc.

Or with newer applications, the access would be ODBC, or a message
queue, or—closest to what you're doing—with the database directly e.g.
MariaDB and the mysql -u RemoteUser -p -h 203.0.113.13 command, etc.

This whole area—FAL, RMS, the file system itself, remote mounts,
database support—is dated, as compared with the other platforms many of
us are now working with.

And in more general terms, I am un-fond of exposing the database
structures remotely whether by classic FAL and RMS or file share or
otherwise, as that makes modifications more difficult. Modifying an RMS
database when its internal structures have escaped the API layer and
becomes known to apps is un-fun. q.v. SYSUAF.DAT, etc. Which further
reduces my interest in using FAL and RMS, beyond discussions of the
authentication and encryption issues. And anybody still using FAL and
RMS and DECnet almost assuredly already knows about this difficulty.

My preference would be to move out of RMS for storage for many
production apps, though that migration is less than easy for entrenched
configurations, and any migration necessarily incremental for many.
Post by Dave Froble
Judged for use today, yes, the original development should not be
judged by today, unless a time machine was available to the developers.
If DECnet is in use today, then it is a risk today, and can be or is
targeted today.
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2021-05-12 12:17:00 UTC
Reply
Permalink
Post by Stephen Hoffman
And in more general terms, I am un-fond of exposing the database
structures remotely whether by classic FAL and RMS or file share or
otherwise, as that makes modifications more difficult.
Agreed. It would have been nicer if RMS indexed files were treated
as a series of structured fields instead of as an indexed version
of a punched card.

That would also need some kind of optional record tag at RMS level
however to identify the record layout in case someone tried to store
records with different internal layouts into the same RMS indexed file.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Jan-Erik Söderholm
2021-05-12 12:24:51 UTC
Reply
Permalink
Post by Simon Clubley
Post by Stephen Hoffman
And in more general terms, I am un-fond of exposing the database
structures remotely whether by classic FAL and RMS or file share or
otherwise, as that makes modifications more difficult.
Agreed. It would have been nicer if RMS indexed files were treated
as a series of structured fields instead of as an indexed version
of a punched card.
That would also need some kind of optional record tag at RMS level
however to identify the record layout in case someone tried to store
records with different internal layouts into the same RMS indexed file.
Simon.
Well, to be fair, RMS indexed files are no different then any other
implementation of "ISAM" files at the time. And on VMS, if you want
something more structured, you would use Rdb.
Arne Vajhøj
2021-05-12 13:10:40 UTC
Reply
Permalink
Post by Simon Clubley
Post by Stephen Hoffman
And in more general terms, I am un-fond of exposing the database
structures remotely whether by classic FAL and RMS or file share or
otherwise, as that makes modifications more difficult.
Agreed. It would have been nicer if RMS indexed files were treated
as a series of structured fields instead of as an indexed version
of a punched card.
I would say no to that.

One could say that it would be nice if a car could fly, but then
it would be an airplane not a car.

The functionality provided is common functionality.

40 years ago all OS had something like this (VMS, IBM mainframe,
CDC, ICL etc.). Even Unix got DBM.

Today new implementations are being developed. It is just called
NoSQL Key Value Store today but is really the same thing. All
the modern internet companies use such technology and many invented
new implementations (Google - LevelDB, Facebook - RocksDB,
LinkedIn - Voldemort).

It is required functionality. We should not get rid of it.

It is not the best choice as frequently as it was. If I were
to provide some random numbers then I would say that best choice
distribution has changed like below.

40 years ago:
- 20% RDBMS
- 80% ISAM/index-sequential file

Today:
- 70% RDBMS
- 20% NoSQL Document Store
- 10% NoSQL Key Value Store

The demand still exist, so we should not get rid of it.
And changing it to do something else than storing
key(s) + value BLOB is de facto getting rid of it.
Post by Simon Clubley
That would also need some kind of optional record tag at RMS level
however to identify the record layout in case someone tried to store
records with different internal layouts into the same RMS indexed file.
Except that the ability to store different record formats in the same
file is core functionality.

Some need that.

Those that need structure should chose a tool that provides
structure and constraints. RDBMS is pretty obvious. SQLite or
other.

Arne
Simon Clubley
2021-05-12 17:09:06 UTC
Reply
Permalink
Post by Arne Vajhøj
One could say that it would be nice if a car could fly, but then
it would be an airplane not a car.
Are you sure about that ? :-)

https://en.wikipedia.org/wiki/Flying_car

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Galen
2021-05-13 01:59:34 UTC
Reply
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
One could say that it would be nice if a car could fly, but then
it would be an airplane not a car.
Are you sure about that ? :-)
https://en.wikipedia.org/wiki/Flying_car
Simon.
Even if flyable cars should become a real thing, let’s hope that operating
large aircraft from highways never does. :-)
Dave Froble
2021-05-13 04:39:28 UTC
Reply
Permalink
Post by Galen
Post by Simon Clubley
Post by Arne Vajhøj
One could say that it would be nice if a car could fly, but then
it would be an airplane not a car.
Are you sure about that ? :-)
https://en.wikipedia.org/wiki/Flying_car
Simon.
Even if flyable cars should become a real thing, let’s hope that operating
large aircraft from highways never does. :-)
What's "large"?

A-10 ?
F-15 ?

I think that already happens.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Bill Gunshannon
2021-05-13 12:12:58 UTC
Reply
Permalink
Post by Dave Froble
Post by Galen
Post by Simon Clubley
Post by Arne Vajhøj
One could say that it would be nice if a car could fly, but then
it would be an airplane not a car.
Are you sure about that ? :-)
https://en.wikipedia.org/wiki/Flying_car
Simon.
Even if flyable cars should become a real thing, let’s hope that operating
large aircraft from highways never does. :-)
What's "large"?
A-10 ?
F-15 ?
I think that already happens.
Back in the days when stealth was still stealth we had an appearance
by the F-117 at a local air show. It was only a flyover as they were
not letting people get an up-close look at the plane. They shut down
the northern end of our turnpike extension and used the highway as a
staging and refueling site.

bill
Galen
2021-05-14 00:42:40 UTC
Reply
Permalink
Post by Dave Froble
What's "large"?
A-10 ?
F-15 ?
I should have been more specific. I was thinking more the size of a C-5 or
An-225, or even a mere 747.

The Swedish Air Force, under its Bas 60 and later Bas 90 basing plans of
the Cold War era, planned for the use of sections public roads near its
airbases as backup runways and had aircraft like the excellent Saab 37
Viggen fighter that were capable of used them.
Dave Froble
2021-05-14 03:13:31 UTC
Reply
Permalink
Post by Galen
Post by Dave Froble
What's "large"?
A-10 ?
F-15 ?
I should have been more specific. I was thinking more the size of a C-5 or
An-225, or even a mere 747.
The Swedish Air Force, under its Bas 60 and later Bas 90 basing plans of
the Cold War era, planned for the use of sections public roads near its
airbases as backup runways and had aircraft like the excellent Saab 37
Viggen fighter that were capable of used them.
At least in some places the roads were shut down for aircraft practice.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-05-12 13:19:37 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by Dave Froble
Open "DFE90A::[DFE]DATA.DAT" For Input as File #1%
Assuming proxys are set appropriately.
Open "DFE90A"DFE XXX"::[DFE]DATA.DAT" For Input as File #1%
If I even remember how to do that correctly ...
What you're doing with RMS and FAL is entirely feasible, though through
different means.
MOUNT the remote system, and access it locally. With newer systems,
that'd usually be an SMB mount, though OpenVMS lacks modern storage
connections. On OpenVMS, it'd be NFS, or maybe DFS. Then aim SQLite at
it, etc.
Or with newer applications, the access would be ODBC, or a message
queue, or—closest to what you're doing—with the database directly e.g.
MariaDB and the mysql -u RemoteUser -p -h 203.0.113.13 command, etc.
There are obviously many ways to access data on other servers.

But neither the ability to mount a remote file system or access
a remote database server is a 1:1 substitute for transparent
file access to remote file system.
Post by Stephen Hoffman
This whole area—FAL, RMS, the file system itself, remote mounts,
database support—is dated, as compared with the other platforms many of
us are now working with.
And in more general terms, I am un-fond of exposing the database
structures remotely whether by classic FAL and RMS or file share or
otherwise, as that makes modifications more difficult. Modifying an RMS
database when its internal structures have escaped the API layer and
becomes known to apps is un-fun. q.v. SYSUAF.DAT, etc. Which further
reduces my interest in using FAL and RMS, beyond discussions of the
authentication and encryption issues. And anybody still using FAL and
RMS and DECnet almost assuredly already knows about this difficulty.
My preference would be to move out of RMS for storage for many
production apps, though that migration is less than easy for entrenched
configurations, and any migration necessarily incremental for many.
If one starts with a blank piece of paper, then relying on
files in the file system is likely not a good choice. Bad
scalability, bad performance etc.. Some sort of database
(RDBMS or NoSQL DS or NoSQL KVS) will typical be much better.

But in the real world starting with a blank piece of paper
is pretty rare.

Arne
Stephen Hoffman
2021-05-12 16:23:31 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Stephen Hoffman
Post by Dave Froble
Open "DFE90A::[DFE]DATA.DAT" For Input as File #1%
Assuming proxys are set appropriately.
Open "DFE90A"DFE XXX"::[DFE]DATA.DAT" For Input as File #1%
If I even remember how to do that correctly ...
What you're doing with RMS and FAL is entirely feasible, though through
different means.
MOUNT the remote system, and access it locally. With newer systems,
that'd usually be an SMB mount, though OpenVMS lacks modern storage
connections. On OpenVMS, it'd be NFS, or maybe DFS. Then aim SQLite at
it, etc.
Or with newer applications, the access would be ODBC, or a message
queue, or—closest to what you're doing—with the database directly e.g.
MariaDB and the mysql -u RemoteUser -p -h 203.0.113.13 command, etc.
There are obviously many ways to access data on other servers.
But neither the ability to mount a remote file system or access a
remote database server is a 1:1 substitute for transparent file access
to remote file system.
I've encountered folks using FAL to access files within an OpenVMS
Cluster, BTW. And sacrilegious as it might be, SMB shares aren't that
far off of SCS MSCP served storage within a Cluster, either. Though
that then descends into discussions of locking. Which then descends
into discussions of why some RMS apps can't be migrated into
network-remote-capable databases. Which descends into why
new-to-OpenVMS folks just aren't picking OpenVMS for new app work. I've
undoubtedly skipped a few intermediate steps in the usual discussion
there, though.

And for the three or twelve folks still using this particular part of
DECnet and RMS and FAL for remote direct and unencrypted database
access, I'd suggest starting to work on refactoring and redesigning
this particular part of the implementation. In this case, API and
abstraction-related work toward removing this is also work toward
allowing a migration to a different and more capable database than the
features that RMS offers, too.

Encrypted SMB shares are endemic and inexpensive and effective, too.
OpenVMS Clusters, and DECnet, not so much.
Post by Arne Vajhøj
But in the real world starting with a blank piece of paper is pretty rare.
Of the various app ports off of OpenVMS that I've worked and of those
others I'm familiar with, I've met none blocked by a lack of FAL-like
storage access.

I liked DECnet. Unfortunately, DEC technical and senior management, um,
"missed the networking market", and we've all been dealing with the
ensuing fallout from that era.

Nothing here precludes an IP-based FAL-like implementation, either. But
I foresee little value implementing that, given file shares and given
network-remote database access.
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2021-05-12 17:15:21 UTC
Reply
Permalink
Post by Stephen Hoffman
And for the three or twelve folks still using this particular part of
DECnet and RMS and FAL for remote direct and unencrypted database
access, I'd suggest starting to work on refactoring and redesigning
this particular part of the implementation.
Before you downplay the number of people still using any specific part
of DECnet Phase IV, just remember that VSI had to port it to x86-64 VMS
way earlier than it would otherwise have done due to the sheer demand
for it on x86-64 VMS.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Stephen Hoffman
2021-05-12 17:41:53 UTC
Reply
Permalink
Post by Simon Clubley
Post by Stephen Hoffman
And for the three or twelve folks still using this particular part of
DECnet and RMS and FAL for remote direct and unencrypted database
access, I'd suggest starting to work on refactoring and redesigning
this particular part of the implementation.
Before you downplay the number of people still using any specific part
of DECnet Phase IV, just remember that VSI had to port it to x86-64 VMS
way earlier than it would otherwise have done due to the sheer demand
for it on x86-64 VMS.
DECnet use is still common, due to a less than robust migration path.

Remote DECnet FAL for shared-file-access use, rather less common. I'd
hope. That's just asking for trouble.

I don't see a great future in DECnet generally, or for FAL
shared-file-access among specific features.

I do see ample room for vastly better IP integration, and a better path
away from DECnet. Maybe that turns into scp/sftp-integrated FAL-ish
support, too. But I'd doubt that. That's unlikely to ever make a VSI
schedule. SMB client integration would be far easier to market, and
more useful.

Unfortunately, OpenVMS has long had more of a grudging-at-best
relationship with IP support and with recent networking—V6.2 and the
associated IP work was a quarter-century ago, this week—so I'm less
than hopeful.
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2021-05-12 17:59:20 UTC
Reply
Permalink
Post by Stephen Hoffman
DECnet use is still common, due to a less than robust migration path.
Remote DECnet FAL for shared-file-access use, rather less common. I'd
hope. That's just asking for trouble.
I don't see a great future in DECnet generally, or for FAL
shared-file-access among specific features.
I would write that as "I _hope_ there isn't a great future for DECnet
generally". :-)

The fact that people are still demanding it in 2021 does make me wonder.
Post by Stephen Hoffman
I do see ample room for vastly better IP integration, and a better path
away from DECnet. Maybe that turns into scp/sftp-integrated FAL-ish
support, too. But I'd doubt that. That's unlikely to ever make a VSI
schedule. SMB client integration would be far easier to market, and
more useful.
The filesystem over SSH work that is showing up elsewhere would be
nice on VMS as well. I don't know what changes would be needed to
VMS to make that possible however.

Done properly, and with VMS specific support for non-sequential
files if needed, that could be the way forward. It would ideally have
the kind of tight integration into VMS that FAL currently has however.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Stephen Hoffman
2021-05-12 18:34:36 UTC
Reply
Permalink
Post by Stephen Hoffman
I do see ample room for vastly better IP integration, and a better path
away from DECnet. Maybe that turns into scp/sftp-integrated FAL-ish
support, too. But I'd doubt that. That's unlikely to ever make a VSI
schedule. SMB client integration would be far easier to market, and
more useful.
The filesystem over SSH work that is showing up elsewhere would be nice
on VMS as well. I don't know what changes would be needed to VMS to
make that possible however.
Having networking from this millennium would be nice, yes.
Done properly, and with VMS specific support for non-sequential files
if needed, that could be the way forward. It would ideally have the
kind of tight integration into VMS that FAL currently has however.
It'd be entertaining to see FAL upgraded to support keyed access into
SQLite and other databases, too.

IIRC, FAL over IP was looked at back around Y2K, and the DECnet-related
FAL-client bits within RMS were well contained. This'd mean
establishing an IP FAL server, as well.

Fix the DECnet security and authentication messes, fix the lack of
networking integration within DCL, and drag the integrated database
support forward, file share client support, and maybe this whole area
gets somewhat more interesting.

To bring OpenVMS out of its current embedded-server status, the sheer
scale of the work ahead for VSI—past the port—cannot be underestimated.

But again, I just don't see FAL-presenting RMS files directly as being
viable, as compared with existing and widespread ODBC and similar
presentations. Though this is OpenVMS, so change can be an anathema.
--
Pure Personal Opinion | HoffmanLabs LLC
Dave Froble
2021-05-13 00:01:54 UTC
Reply
Permalink
Post by Simon Clubley
Post by Stephen Hoffman
DECnet use is still common, due to a less than robust migration path.
Remote DECnet FAL for shared-file-access use, rather less common. I'd
hope. That's just asking for trouble.
I don't see a great future in DECnet generally, or for FAL
shared-file-access among specific features.
I would write that as "I _hope_ there isn't a great future for DECnet
generally". :-)
The fact that people are still demanding it in 2021 does make me wonder.
There most likely is no future for DECnet.

Would I ever use FAL in an application? Not a chance.

If I have ever used a feature even once, then I found the feature
useful, and would not consider it a bad thing. Doesn't mean I'd use it
in an application.

Without researching it, I'm guessing that FAL might be involved in
BACKUP to a save set on a remote node. That by itself justifies FAL.

I'm guessing that when VSI asked customers "do you use DECnet" there was
plenty of positive answers. Possibly because it was needed, more likely
because it is useful.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-05-12 17:24:10 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by Arne Vajhøj
Post by Stephen Hoffman
What you're doing with RMS and FAL is entirely feasible, though
through different means.
MOUNT the remote system, and access it locally. With newer systems,
that'd usually be an SMB mount, though OpenVMS lacks modern storage
connections. On OpenVMS, it'd be NFS, or maybe DFS. Then aim SQLite
at it, etc.
Or with newer applications, the access would be ODBC, or a message
queue, or—closest to what you're doing—with the database directly
e.g. MariaDB and the mysql -u RemoteUser -p -h 203.0.113.13 command,
etc.
There are obviously many ways to access data on other servers.
But neither the ability to mount a remote file system or access a
remote database server is a 1:1 substitute for transparent file access
to remote file system.
I've encountered folks using FAL to access files within an OpenVMS
Cluster, BTW. And sacrilegious as it might be, SMB shares aren't that
far off of SCS MSCP served storage within a Cluster, either. Though that
then descends into discussions of locking. Which then descends into
discussions of why some RMS apps can't be migrated into
network-remote-capable databases. Which descends into why new-to-OpenVMS
folks just aren't picking OpenVMS for new app work. I've undoubtedly
skipped a few intermediate steps in the usual discussion there, though.
And for the three or twelve folks still using this particular part of
DECnet and RMS and FAL for remote direct and unencrypted database
access, I'd suggest starting to work on refactoring and redesigning this
particular part of the implementation. In this case, API and
abstraction-related work toward removing this is also work toward
allowing a migration to a different and more capable database than the
features that RMS offers, too.
Encrypted SMB shares are endemic and inexpensive and effective, too.
OpenVMS Clusters, and DECnet, not so much.
Yes.

But "refactoring and redesigning" is work.
Post by Stephen Hoffman
Post by Arne Vajhøj
But in the real world starting with a blank piece of paper is pretty rare.
Of the various app ports off of OpenVMS that I've worked and of those
others I'm familiar with, I've met none blocked by a lack of FAL-like
storage access.
That quote from me was about file vs database not about FAL vs other
file access.

You may have encountered projects where file to database was
a real issue.

Arne
Stephen Hoffman
2021-05-12 17:56:10 UTC
Reply
Permalink
You may have encountered projects where file to database was a real issue.
Extracting or abstracting the language-specific RMS extensions tends to
be the bulk of that porting project.

Capabilities of databases over RMS, ~never.

I've rarely met production apps using remote file sharing with FAL, and
not in many years.

DCL remains incompetent at basic networking.

At basic networking from this millennium, that is.

RMS networking too, as there's nothing that would preclude RMS from
being extended to use IP for FAL-like or even FAL-based access. With
TLS.
--
Pure Personal Opinion | HoffmanLabs LLC
Bill Gunshannon
2021-05-12 19:30:23 UTC
Reply
Permalink
Post by Arne Vajhøj
That quote from me was about file vs database not about FAL vs other
file access.
You may have encountered projects where file to database was
a real issue.
I have encountered file to database projects that were absolutely
hilarious.

bill
Dave Froble
2021-05-17 02:21:28 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by Stephen Hoffman
Post by Dave Froble
Open "DFE90A::[DFE]DATA.DAT" For Input as File #1%
Assuming proxys are set appropriately.
Open "DFE90A"DFE XXX"::[DFE]DATA.DAT" For Input as File #1%
If I even remember how to do that correctly ...
What you're doing with RMS and FAL is entirely feasible, though through
different means.
MOUNT the remote system, and access it locally. With newer systems,
that'd usually be an SMB mount, though OpenVMS lacks modern storage
connections. On OpenVMS, it'd be NFS, or maybe DFS. Then aim SQLite at
it, etc.
Or with newer applications, the access would be ODBC, or a message
queue, or—closest to what you're doing—with the database directly e.g.
MariaDB and the mysql -u RemoteUser -p -h 203.0.113.13 command, etc.
This whole area—FAL, RMS, the file system itself, remote mounts,
database support—is dated, as compared with the other platforms many of
us are now working with.
If I was using the network access in general, your suggestions might
have merit. If every now and then, not part of any production, I wish
to grab some data, then the existing DECnet capabilities are helpful.
Post by Stephen Hoffman
Post by Stephen Hoffman
And in more general terms, I am un-fond of exposing the database
structures remotely whether by classic FAL and RMS or file share or
otherwise, as that makes modifications more difficult. Modifying an RMS
database when its internal structures have escaped the API layer and
becomes known to apps is un-fun. q.v. SYSUAF.DAT, etc. Which further
reduces my interest in using FAL and RMS, beyond discussions of the
authentication and encryption issues. And anybody still using FAL and
RMS and DECnet almost assuredly already knows about this difficulty.
My preference would be to move out of RMS for storage for many
production apps,
Good than that I don't use RMS, huh?
Post by Stephen Hoffman
though that migration is less than easy for entrenched
Post by Stephen Hoffman
configurations, and any migration necessarily incremental for many.
Post by Dave Froble
Judged for use today, yes, the original development should not be
judged by today, unless a time machine was available to the developers.
If DECnet is in use today, then it is a risk today, and can be or is
targeted today.
--
Pure Personal Opinion | HoffmanLabs LLC
I was told by Process Software years ago that "for a price" they could make it possible to run their TCPware Decnet Phase IV over IP connection thru an SSH tunnel.
If Process can do it why hasn't HP then or VSI now done it already?
Why is your answer one of directing users to shy away from using a great protocol and one that makes OpenVMS unique?
What happened to product enhancements?
DECnet, while a good thing in the past, isn't the future. Work on it
just isn't worth the time and money. Work on TCP/IP is worth the time
and expense, hoping that happens.

I guess you missed Clair Grant's desire to not port DECnet to x86.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-05-17 12:24:28 UTC
Reply
Permalink
Post by Stephen Hoffman
I was told by Process Software years ago that "for a price" they could make it possible to run their TCPware Decnet Phase IV over IP connection thru an SSH tunnel.
If Process can do it why hasn't HP then or VSI now done it already?
Why is your answer one of directing users to shy away from using a great protocol and one that makes OpenVMS unique?
There's nothing great about DECnet in 2021. When it was created
it was a good protocol for the time, but that time passed decades ago.
Post by Stephen Hoffman
What happened to product enhancements?
I wonder if there are also some in the IBM mainframe world who
want to go back to using only SNA and think that it's somehow
a lot better than all that new-fangled TCP/IP stuff ? :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Bill Gunshannon
2021-05-17 12:42:13 UTC
Reply
Permalink
Post by Simon Clubley
Post by Stephen Hoffman
I was told by Process Software years ago that "for a price" they could make it possible to run their TCPware Decnet Phase IV over IP connection thru an SSH tunnel.
If Process can do it why hasn't HP then or VSI now done it already?
Why is your answer one of directing users to shy away from using a great protocol and one that makes OpenVMS unique?
Just what is the advantage of being "unique" in the IT world today?
Post by Simon Clubley
There's nothing great about DECnet in 2021. When it was created
it was a good protocol for the time, but that time passed decades ago.
Post by Stephen Hoffman
What happened to product enhancements?
I wonder if there are also some in the IBM mainframe world who
want to go back to using only SNA and think that it's somehow
a lot better than all that new-fangled TCP/IP stuff ? :-)
SNA hell... Let's get rid of this damn Ethernet stuff and get on
with Token Ring the way it was meant to be.

bill
V***@SendSpamHere.ORG
2021-05-17 18:19:06 UTC
Reply
Permalink
Post by Bill Gunshannon
Post by Simon Clubley
Post by Stephen Hoffman
I was told by Process Software years ago that "for a price" they could make it possible to run their TCPware Decnet Phase IV over IP connection thru an SSH tunnel.
If Process can do it why hasn't HP then or VSI now done it already?
Why is your answer one of directing users to shy away from using a great protocol and one that makes OpenVMS unique?
Just what is the advantage of being "unique" in the IT world today?
Post by Simon Clubley
There's nothing great about DECnet in 2021. When it was created
it was a good protocol for the time, but that time passed decades ago.
Post by Stephen Hoffman
What happened to product enhancements?
I wonder if there are also some in the IBM mainframe world who
want to go back to using only SNA and think that it's somehow
a lot better than all that new-fangled TCP/IP stuff ? :-)
SNA hell... Let's get rid of this damn Ethernet stuff and get on
with Token Ring the way it was meant to be.
LOL!
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
V***@SendSpamHere.ORG
2021-05-17 18:20:48 UTC
Reply
Permalink
Post by Simon Clubley
Post by Stephen Hoffman
I was told by Process Software years ago that "for a price" they could make it possible to run their TCPware Decnet Phase IV over IP connection thru an SSH tunnel.
If Process can do it why hasn't HP then or VSI now done it already?
Why is your answer one of directing users to shy away from using a great protocol and one that makes OpenVMS unique?
There's nothing great about DECnet in 2021. When it was created
it was a good protocol for the time, but that time passed decades ago.
Please tell me now to SYS$OPEN a file on another host with TCP/IP.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Simon Clubley
2021-05-17 19:22:25 UTC
Reply
Permalink
Post by V***@SendSpamHere.ORG
Post by Simon Clubley
Post by Stephen Hoffman
I was told by Process Software years ago that "for a price" they could make it possible to run their TCPware Decnet Phase IV over IP connection thru an SSH tunnel.
If Process can do it why hasn't HP then or VSI now done it already?
Why is your answer one of directing users to shy away from using a great protocol and one that makes OpenVMS unique?
There's nothing great about DECnet in 2021. When it was created
it was a good protocol for the time, but that time passed decades ago.
Please tell me now to SYS$OPEN a file on another host with TCP/IP.
Times change Brian and how you implement such things changes as well.

There are multiple options. You could use CIFS or NFS (for example).

There's work going on with filesystems over SSH. Whether VMS will ever
see any of that work is another matter.

If the other node is in a VMS cluster, you don't need DECnet.

For an example of a different approach in the Linux world, there's GFS2:

https://en.wikipedia.org/wiki/GFS2

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
ultr...@gmail.com
2021-05-18 00:22:02 UTC
Reply
Permalink
Post by Simon Clubley
Post by V***@SendSpamHere.ORG
Post by Simon Clubley
Post by Stephen Hoffman
I was told by Process Software years ago that "for a price" they could make it possible to run their TCPware Decnet Phase IV over IP connection thru an SSH tunnel.
If Process can do it why hasn't HP then or VSI now done it already?
Why is your answer one of directing users to shy away from using a great protocol and one that makes OpenVMS unique?
There's nothing great about DECnet in 2021. When it was created
it was a good protocol for the time, but that time passed decades ago.
Please tell me now to SYS$OPEN a file on another host with TCP/IP.
Times change Brian and how you implement such things changes as well.
There are multiple options. You could use CIFS or NFS (for example).
There's work going on with filesystems over SSH. Whether VMS will ever
see any of that work is another matter.
If the other node is in a VMS cluster, you don't need DECnet.
https://en.wikipedia.org/wiki/GFS2
Simon.
--
Walking destinations on a map are further away than they appear.
nothing like reinventing the wheel
V***@SendSpamHere.ORG
2021-05-18 00:41:42 UTC
Reply
Permalink
Post by Simon Clubley
Post by V***@SendSpamHere.ORG
Post by Simon Clubley
Post by Stephen Hoffman
I was told by Process Software years ago that "for a price" they could make it possible to run their TCPware Decnet Phase IV over IP connection thru an SSH tunnel.
If Process can do it why hasn't HP then or VSI now done it already?
Why is your answer one of directing users to shy away from using a great protocol and one that makes OpenVMS unique?
There's nothing great about DECnet in 2021. When it was created
it was a good protocol for the time, but that time passed decades ago.
Please tell me now to SYS$OPEN a file on another host with TCP/IP.
Times change Brian and how you implement such things changes as well.
There are multiple options. You could use CIFS or NFS (for example).
There's work going on with filesystems over SSH. Whether VMS will ever
see any of that work is another matter.
If the other node is in a VMS cluster, you don't need DECnet.
https://en.wikipedia.org/wiki/GFS2
NODE::DEVICE:[DIRECTORY]FILENAME.EXT;VERSION
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Dave Froble
2021-05-18 02:53:54 UTC
Reply
Permalink
Post by V***@SendSpamHere.ORG
Post by Simon Clubley
Post by V***@SendSpamHere.ORG
Post by Simon Clubley
Post by Stephen Hoffman
I was told by Process Software years ago that "for a price" they could make it possible to run their TCPware Decnet Phase IV over IP connection thru an SSH tunnel.
If Process can do it why hasn't HP then or VSI now done it already?
Why is your answer one of directing users to shy away from using a great protocol and one that makes OpenVMS unique?
There's nothing great about DECnet in 2021. When it was created
it was a good protocol for the time, but that time passed decades ago.
Please tell me now to SYS$OPEN a file on another host with TCP/IP.
Times change Brian and how you implement such things changes as well.
There are multiple options. You could use CIFS or NFS (for example).
There's work going on with filesystems over SSH. Whether VMS will ever
see any of that work is another matter.
If the other node is in a VMS cluster, you don't need DECnet.
https://en.wikipedia.org/wiki/GFS2
NODE::DEVICE:[DIRECTORY]FILENAME.EXT;VERSION
It's a bit funny, and a lot sad, that even though people know what they
are advocating doesn't exist, they still promote it.

As far as I know, GFS2 doesn't exist on VMS. Somebody know something I
don't know?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-05-18 11:51:45 UTC
Reply
Permalink
Post by Dave Froble
Post by V***@SendSpamHere.ORG
Post by Simon Clubley
Post by V***@SendSpamHere.ORG
Please tell me now to SYS$OPEN a file on another host with TCP/IP.
Times change Brian and how you implement such things changes as well.
There are multiple options. You could use CIFS or NFS (for example).
There's work going on with filesystems over SSH. Whether VMS will ever
see any of that work is another matter.
If the other node is in a VMS cluster, you don't need DECnet.
https://en.wikipedia.org/wiki/GFS2
NODE::DEVICE:[DIRECTORY]FILENAME.EXT;VERSION
It's a bit funny, and a lot sad, that even though people know what they
are advocating doesn't exist, they still promote it.
As far as I know, GFS2 doesn't exist on VMS.  Somebody know something I
don't know?
GFS2 sort of exist on VMS. And has since way before GFS2 was invented.

:-)

GFS2 is a cluster wide accessible file system using a distributed
lock manager to control access.

Just like VMS has done it for almost 40 years.

And it is not just functional equivalent. Supposedly the
DLM design went VMS -> Tru64 -> Linux.

And the API sure does look familiar:

int dlm_lock(uint32_t mode,
struct dlm_lksb *lksb,
uint32_t flags,
const void *name,
unsigned int namelen,
uint32_t parent, /* unused */
void (*astaddr) (void *astarg),
void *astarg,
void (*bastaddr) (void *astarg),
void *range); /* unused */

On the other side then cluster wide mount and transparent
file access to remote files is still not the exact same thing.

Oh and to complete the story, then VSI has announced that they plan
on porting GFS2 to VMS (to get around certain limitations in current
file systems). Current roadmap says after 9.2 aka 9.3 or 10.0.

Arne
ultr...@gmail.com
2021-05-18 15:53:09 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Dave Froble
Post by V***@SendSpamHere.ORG
Post by Simon Clubley
Post by V***@SendSpamHere.ORG
Please tell me now to SYS$OPEN a file on another host with TCP/IP.
Times change Brian and how you implement such things changes as well.
There are multiple options. You could use CIFS or NFS (for example).
There's work going on with filesystems over SSH. Whether VMS will ever
see any of that work is another matter.
If the other node is in a VMS cluster, you don't need DECnet.
https://en.wikipedia.org/wiki/GFS2
NODE::DEVICE:[DIRECTORY]FILENAME.EXT;VERSION
It's a bit funny, and a lot sad, that even though people know what they
are advocating doesn't exist, they still promote it.
As far as I know, GFS2 doesn't exist on VMS. Somebody know something I
don't know?
GFS2 sort of exist on VMS. And has since way before GFS2 was invented.
:-)
GFS2 is a cluster wide accessible file system using a distributed
lock manager to control access.
Just like VMS has done it for almost 40 years.
And it is not just functional equivalent. Supposedly the
DLM design went VMS -> Tru64 -> Linux.
int dlm_lock(uint32_t mode,
struct dlm_lksb *lksb,
uint32_t flags,
const void *name,
unsigned int namelen,
uint32_t parent, /* unused */
void (*astaddr) (void *astarg),
void *astarg,
void (*bastaddr) (void *astarg),
void *range); /* unused */
On the other side then cluster wide mount and transparent
file access to remote files is still not the exact same thing.
Oh and to complete the story, then VSI has announced that they plan
on porting GFS2 to VMS (to get around certain limitations in current
file systems). Current roadmap says after 9.2 aka 9.3 or 10.0.
Arne
so another part of VMS stolen just like windows NT?
Dave Froble
2021-05-18 18:18:52 UTC
Reply
Permalink
Post by ***@gmail.com
Post by Arne Vajhøj
Post by Dave Froble
Post by V***@SendSpamHere.ORG
Post by Simon Clubley
Post by V***@SendSpamHere.ORG
Please tell me now to SYS$OPEN a file on another host with TCP/IP.
Times change Brian and how you implement such things changes as well.
There are multiple options. You could use CIFS or NFS (for example).
There's work going on with filesystems over SSH. Whether VMS will ever
see any of that work is another matter.
If the other node is in a VMS cluster, you don't need DECnet.
https://en.wikipedia.org/wiki/GFS2
NODE::DEVICE:[DIRECTORY]FILENAME.EXT;VERSION
It's a bit funny, and a lot sad, that even though people know what they
are advocating doesn't exist, they still promote it.
As far as I know, GFS2 doesn't exist on VMS. Somebody know something I
don't know?
GFS2 sort of exist on VMS. And has since way before GFS2 was invented.
:-)
GFS2 is a cluster wide accessible file system using a distributed
lock manager to control access.
Just like VMS has done it for almost 40 years.
And it is not just functional equivalent. Supposedly the
DLM design went VMS -> Tru64 -> Linux.
int dlm_lock(uint32_t mode,
struct dlm_lksb *lksb,
uint32_t flags,
const void *name,
unsigned int namelen,
uint32_t parent, /* unused */
void (*astaddr) (void *astarg),
void *astarg,
void (*bastaddr) (void *astarg),
void *range); /* unused */
On the other side then cluster wide mount and transparent
file access to remote files is still not the exact same thing.
Oh and to complete the story, then VSI has announced that they plan
on porting GFS2 to VMS (to get around certain limitations in current
file systems). Current roadmap says after 9.2 aka 9.3 or 10.0.
Arne
so another part of VMS stolen just like windows NT?
"Stolen" ???

I thought copying was flattery. Nothing wrong with using a good idea.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Craig A. Berry
2021-05-18 11:56:37 UTC
Reply
Permalink
Post by Dave Froble
As far as I know, GFS2 doesn't exist on VMS.  Somebody know something I
don't know?
I believe it was on the roadmap, replacing VAFS, which was previously on
the roadmap. Neither is there now. There was a big discussion here
last fall about how they could possibly include GFS2 in VMS given its
GPL license.
Simon Clubley
2021-05-18 19:13:37 UTC
Reply
Permalink
Post by Craig A. Berry
Post by Dave Froble
As far as I know, GFS2 doesn't exist on VMS.  Somebody know something I
don't know?
I believe it was on the roadmap, replacing VAFS, which was previously on
the roadmap. Neither is there now. There was a big discussion here
last fall about how they could possibly include GFS2 in VMS given its
GPL license.
I was responsible for that discussion. :-)

We never did get any firm answers to the question about why VSI
thought GPL code would not be a problem for the VMS kernel,
unless they were planning some form of a new clean room implementation.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Simon Clubley
2021-05-18 18:55:13 UTC
Reply
Permalink
Post by Dave Froble
It's a bit funny, and a lot sad, that even though people know what they
are advocating doesn't exist, they still promote it.
The point of the list was to give Brian some ideas that do work
on VMS (NFS for example) and also list how this is done on other
operating systems using some options that do not currently work
on VMS.

IOW, there are a number of ways to do what Brian is asking for.

You just need to have the functionality in the operating system
in question to do it in all of those ways.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
ultr...@gmail.com
2021-05-19 21:46:59 UTC
Reply
Permalink
Post by Simon Clubley
Post by Dave Froble
It's a bit funny, and a lot sad, that even though people know what they
are advocating doesn't exist, they still promote it.
The point of the list was to give Brian some ideas that do work
on VMS (NFS for example) and also list how this is done on other
operating systems using some options that do not currently work
on VMS.
IOW, there are a number of ways to do what Brian is asking for.
You just need to have the functionality in the operating system
in question to do it in all of those ways.
Simon.
--
Walking destinations on a map are further away than they appear.
there are us actual OpenVMS users who actually like the VMS file and command implementation
and don't want to become linucized.

If you love that crap OS so much use it but don't force those crap extensions on us.
Dave Froble
2021-05-19 22:00:30 UTC
Reply
Permalink
Post by ***@gmail.com
Post by Simon Clubley
Post by Dave Froble
It's a bit funny, and a lot sad, that even though people know what they
are advocating doesn't exist, they still promote it.
The point of the list was to give Brian some ideas that do work
on VMS (NFS for example) and also list how this is done on other
operating systems using some options that do not currently work
on VMS.
IOW, there are a number of ways to do what Brian is asking for.
You just need to have the functionality in the operating system
in question to do it in all of those ways.
Simon.
--
Walking destinations on a map are further away than they appear.
there are us actual OpenVMS users who actually like the VMS file and command implementation
and don't want to become linucized.
If you love that crap OS so much use it but don't force those crap extensions on us.
Every 10-20 years Bob has a winner.

+1
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-05-19 23:22:52 UTC
Reply
Permalink
Post by Dave Froble
Post by ***@gmail.com
Post by Simon Clubley
Post by Dave Froble
It's a bit funny, and a lot sad, that even though people know what they
are advocating doesn't exist, they still promote it.
The point of the list was to give Brian some ideas that do work
on VMS (NFS for example) and also list how this is done on other
operating systems using some options that do not currently work
on VMS.
IOW, there are a number of ways to do what Brian is asking for.
You just need to have the functionality in the operating system
in question to do it in all of those ways.
there are us actual OpenVMS users who actually like the VMS file and command implementation
and don't want to become linucized.
If you love that crap OS so much use it but don't force those crap extensions on us.
Every 10-20 years Bob has a winner.
+1
Not really. If you want VMS to exist tomorrow, then VMS needs to support
the protocols that other operating systems use.

By the reasoning of both of you, then you are saying that if something
didn't originate on VMS, then it should not be used on VMS.

That means no LLVM for x86-64 VMS, no ELF for executable formats,
none of the TCP/IP protocols, no GFS2 (assuming VSI has sorted out
the licencing issues) and that VMS should not run on x86-64.

Is that really what both of you are saying ?

BTW, before Bob comments about security (as he usually does), Linux
has mandatory access controls and other isolation options. What does
VMS have to match that ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-05-19 23:40:47 UTC
Reply
Permalink
Post by Simon Clubley
Post by Dave Froble
Post by ***@gmail.com
Post by Simon Clubley
Post by Dave Froble
It's a bit funny, and a lot sad, that even though people know what they
are advocating doesn't exist, they still promote it.
The point of the list was to give Brian some ideas that do work
on VMS (NFS for example) and also list how this is done on other
operating systems using some options that do not currently work
on VMS.
IOW, there are a number of ways to do what Brian is asking for.
You just need to have the functionality in the operating system
in question to do it in all of those ways.
there are us actual OpenVMS users who actually like the VMS file and command implementation
and don't want to become linucized.
If you love that crap OS so much use it but don't force those crap extensions on us.
Every 10-20 years Bob has a winner.
+1
Not really. If you want VMS to exist tomorrow, then VMS needs to support
the protocols that other operating systems use.
But why can't it continue to support what some of us know, and like?
Post by Simon Clubley
By the reasoning of both of you, then you are saying that if something
didn't originate on VMS, then it should not be used on VMS.
Now there you go again, putting words in other's mouths/fingers. Never
said anything like that at all.
Post by Simon Clubley
That means no LLVM for x86-64 VMS, no ELF for executable formats,
none of the TCP/IP protocols, no GFS2 (assuming VSI has sorted out
the licencing issues) and that VMS should not run on x86-64.
See how you get carried away?
Post by Simon Clubley
Is that really what both of you are saying ?
Where did you read anything like that?
Post by Simon Clubley
BTW, before Bob comments about security (as he usually does), Linux
has mandatory access controls and other isolation options. What does
VMS have to match that ?
No power cord?

Decent app developers?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-05-20 00:00:36 UTC
Reply
Permalink
Post by Dave Froble
Post by Simon Clubley
Post by Dave Froble
Post by ***@gmail.com
Post by Simon Clubley
Post by Dave Froble
It's a bit funny, and a lot sad, that even though people know what they
are advocating doesn't exist, they still promote it.
The point of the list was to give Brian some ideas that do work
on VMS (NFS for example) and also list how this is done on other
operating systems using some options that do not currently work
on VMS.
IOW, there are a number of ways to do what Brian is asking for.
You just need to have the functionality in the operating system
in question to do it in all of those ways.
there are us actual OpenVMS users who actually like the VMS file and command implementation
and don't want to become linucized.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Post by Dave Froble
Post by Simon Clubley
Post by Dave Froble
Post by ***@gmail.com
If you love that crap OS so much use it but don't force those crap extensions on us.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Post by Dave Froble
Post by Simon Clubley
Post by Dave Froble
Every 10-20 years Bob has a winner.
+1
Not really. If you want VMS to exist tomorrow, then VMS needs to support
the protocols that other operating systems use.
But why can't it continue to support what some of us know, and like?
Post by Simon Clubley
By the reasoning of both of you, then you are saying that if something
didn't originate on VMS, then it should not be used on VMS.
Now there you go again, putting words in other's mouths/fingers. Never
said anything like that at all.
Post by Simon Clubley
That means no LLVM for x86-64 VMS, no ELF for executable formats,
none of the TCP/IP protocols, no GFS2 (assuming VSI has sorted out
the licencing issues) and that VMS should not run on x86-64.
See how you get carried away?
Post by Simon Clubley
Is that really what both of you are saying ?
Where did you read anything like that?
I've highlighted the section above.
Post by Dave Froble
Post by Simon Clubley
BTW, before Bob comments about security (as he usually does), Linux
has mandatory access controls and other isolation options. What does
VMS have to match that ?
No power cord?
Decent app developers?
Seriously David ? :-(

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
ultr...@gmail.com
2021-05-20 19:14:45 UTC
Reply
Permalink
Post by Dave Froble
Post by Simon Clubley
Post by Dave Froble
Post by ***@gmail.com
Post by Simon Clubley
Post by Dave Froble
It's a bit funny, and a lot sad, that even though people know what they
are advocating doesn't exist, they still promote it.
The point of the list was to give Brian some ideas that do work
on VMS (NFS for example) and also list how this is done on other
operating systems using some options that do not currently work
on VMS.
IOW, there are a number of ways to do what Brian is asking for.
You just need to have the functionality in the operating system
in question to do it in all of those ways.
there are us actual OpenVMS users who actually like the VMS file and command implementation
and don't want to become linucized.
If you love that crap OS so much use it but don't force those crap extensions on us.
Every 10-20 years Bob has a winner.
+1
Not really. If you want VMS to exist tomorrow, then VMS needs to support
the protocols that other operating systems use.
But why can't it continue to support what some of us know, and like?
Post by Simon Clubley
By the reasoning of both of you, then you are saying that if something
didn't originate on VMS, then it should not be used on VMS.
Now there you go again, putting words in other's mouths/fingers. Never
said anything like that at all.
Post by Simon Clubley
That means no LLVM for x86-64 VMS, no ELF for executable formats,
none of the TCP/IP protocols, no GFS2 (assuming VSI has sorted out
the licencing issues) and that VMS should not run on x86-64.
See how you get carried away?
Post by Simon Clubley
Is that really what both of you are saying ?
Where did you read anything like that?
Post by Simon Clubley
BTW, before Bob comments about security (as he usually does), Linux
has mandatory access controls and other isolation options. What does
VMS have to match that ?
No power cord?
Decent app developers?
--
:)
Post by Dave Froble
David Froble Tel: 724-529-0450
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-05-18 18:49:45 UTC
Reply
Permalink
Post by V***@SendSpamHere.ORG
NODE::DEVICE:[DIRECTORY]FILENAME.EXT;VERSION
And if you use NFS, then its even easier than that.

Times change Brian and what was once considered acceptable may no
longer be considered as such.

To take another example, it was once considered acceptable to
write full normal applications fully in assembly language.
No-one sane does that with any new applications in 2021.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Simon Clubley
2021-05-12 12:10:15 UTC
Reply
Permalink
Post by Dave Froble
Post by Stephen Hoffman
It's a way of directly activating hunks of a captive environment that
might not be accessible directly.
Only if those "hunks" exist.
As I have already mentioned, someone can also copy a command procedure
of their choosing to the captive account using FAL and then execute the
command procedure using one of the two methods.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-05-12 15:23:25 UTC
Reply
Permalink
Post by Simon Clubley
Post by Dave Froble
Post by Stephen Hoffman
It's a way of directly activating hunks of a captive environment that
might not be accessible directly.
Only if those "hunks" exist.
As I have already mentioned, someone can also copy a command procedure
of their choosing to the captive account using FAL and then execute the
command procedure using one of the two methods.
Simon.
Ok. who can create and copy the command procedure?

If limiting activity to the captive account, just how does it get these
command procedures, and how does it copy them?

What you're assuming is that a user already has these authorized
capabilities, and if so, then it is "authorized capabilities".
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-05-12 17:34:35 UTC
Reply
Permalink
Post by Dave Froble
Post by Simon Clubley
As I have already mentioned, someone can also copy a command procedure
of their choosing to the captive account using FAL and then execute the
command procedure using one of the two methods.
Ok. who can create and copy the command procedure?
Now you are just trolling David. However, just in case you really
are serious:

Anyone on the network with a DECnet client and an editor. The DECnet
client doesn't even have to be a VMS-based DECnet client.
Post by Dave Froble
If limiting activity to the captive account, just how does it get these
command procedures, and how does it copy them?
They are pushed to the captive account from across the network.
They are not pulled from the captive account.

To stop this, you have to make absolutely 100% sure that network
mode access is blocked in the captive account. Apart from configuration
mistakes or omissions that might be made in this area, then for some
usage cases you simply cannot do that.
Post by Dave Froble
What you're assuming is that a user already has these authorized
capabilities, and if so, then it is "authorized capabilities".
Well, that's a load of nonsense David.

A user may be authorised to do whatever they want in a non-privileged
account or on another non-critical machine on the network but they are
restricted to a specific workflow when using the captive account on the
target machine.

That doesn't stop them from creating a command procedure with the commands
they would like to run (but are blocked from doing so in their authorised
accounts) and then copying it to the captive account where they can
actually execute those commands.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-05-13 00:13:07 UTC
Reply
Permalink
Post by Simon Clubley
Post by Dave Froble
Post by Simon Clubley
As I have already mentioned, someone can also copy a command procedure
of their choosing to the captive account using FAL and then execute the
command procedure using one of the two methods.
Ok. who can create and copy the command procedure?
Now you are just trolling David. However, just in case you really
I am very serious.
Post by Simon Clubley
Anyone on the network with a DECnet client and an editor. The DECnet
client doesn't even have to be a VMS-based DECnet client.
Post by Dave Froble
If limiting activity to the captive account, just how does it get these
command procedures, and how does it copy them?
They are pushed to the captive account from across the network.
They are not pulled from the captive account.
How does this happen, unless they have write access to the UIC of the
captive account? If they have write access, then they are authorized to
do so.
Post by Simon Clubley
To stop this, you have to make absolutely 100% sure that network
mode access is blocked in the captive account. Apart from configuration
mistakes or omissions that might be made in this area, then for some
usage cases you simply cannot do that.
Makes me wonder if you actually use VMS ...
Post by Simon Clubley
Post by Dave Froble
What you're assuming is that a user already has these authorized
capabilities, and if so, then it is "authorized capabilities".
Well, that's a load of nonsense David.
No, that is exactly what we are discussing.

Any user can only do what they are authorized to do. They cannot access
any files they do not have access to. They cannot place files in any
directory they do not have access to.
Post by Simon Clubley
A user may be authorised to do whatever they want in a non-privileged
account or on another non-critical machine on the network but they are
restricted to a specific workflow when using the captive account on the
target machine.
That doesn't stop them from creating a command procedure with the commands
they would like to run (but are blocked from doing so in their authorised
accounts) and then copying it to the captive account where they can
actually execute those commands.
If they do not have access, as in write privs, to the captive account,
they just how does that happen?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-05-13 04:25:13 UTC
Reply
Permalink
Post by Dave Froble
Post by Simon Clubley
Post by Dave Froble
Post by Simon Clubley
As I have already mentioned, someone can also copy a command procedure
of their choosing to the captive account using FAL and then execute the
command procedure using one of the two methods.
Ok. who can create and copy the command procedure?
Now you are just trolling David. However, just in case you really
I am very serious.
Post by Simon Clubley
Anyone on the network with a DECnet client and an editor. The DECnet
client doesn't even have to be a VMS-based DECnet client.
Post by Dave Froble
If limiting activity to the captive account, just how does it get these
command procedures, and how does it copy them?
They are pushed to the captive account from across the network.
They are not pulled from the captive account.
How does this happen, unless they have write access to the UIC of the
captive account? If they have write access, then they are authorized to
do so.
Because they use FAL to login _as_ the captive account. They do not
log into FAL as themselves.
Post by Dave Froble
Post by Simon Clubley
To stop this, you have to make absolutely 100% sure that network
mode access is blocked in the captive account. Apart from configuration
mistakes or omissions that might be made in this area, then for some
usage cases you simply cannot do that.
Makes me wonder if you actually use VMS ...
I suspect you are in one of those moods of yours where you sometimes
pretend not to understand anything in order to mess with people...
Post by Dave Froble
Post by Simon Clubley
Post by Dave Froble
What you're assuming is that a user already has these authorized
capabilities, and if so, then it is "authorized capabilities".
Well, that's a load of nonsense David.
No, that is exactly what we are discussing.
Any user can only do what they are authorized to do. They cannot access
any files they do not have access to. They cannot place files in any
directory they do not have access to.
Captive accounts are unique in VMS in that the user gets access to
an account with elevated privileges that you would never give them
normally if they had free access to the account.

For that to work however, you need to block off _all_ possible methods
to stop them from executing commands with the privileges of the captive
account and with the current DECnet design, it's possible to for them
to still execute commands of their choosing if they can get logged in
via network mode instead of interactive mode.

As I have just told Tad, the real problem is the ability to execute
transferred command files while in network mode, not the ability to
transfer them in the first place (provided you have sufficiently
protected the existing files that are there).
Post by Dave Froble
Post by Simon Clubley
A user may be authorised to do whatever they want in a non-privileged
account or on another non-critical machine on the network but they are
restricted to a specific workflow when using the captive account on the
target machine.
That doesn't stop them from creating a command procedure with the commands
they would like to run (but are blocked from doing so in their authorised
accounts) and then copying it to the captive account where they can
actually execute those commands.
If they do not have access, as in write privs, to the captive account,
they just how does that happen?
Because they login to FAL _as_ the captive account, not as themselves.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-05-13 04:45:52 UTC
Reply
Permalink
Post by Simon Clubley
Post by Dave Froble
Post by Simon Clubley
Post by Dave Froble
Post by Simon Clubley
As I have already mentioned, someone can also copy a command procedure
of their choosing to the captive account using FAL and then execute the
command procedure using one of the two methods.
Ok. who can create and copy the command procedure?
Now you are just trolling David. However, just in case you really
I am very serious.
Post by Simon Clubley
Anyone on the network with a DECnet client and an editor. The DECnet
client doesn't even have to be a VMS-based DECnet client.
Post by Dave Froble
If limiting activity to the captive account, just how does it get these
command procedures, and how does it copy them?
They are pushed to the captive account from across the network.
They are not pulled from the captive account.
How does this happen, unless they have write access to the UIC of the
captive account? If they have write access, then they are authorized to
do so.
Because they use FAL to login _as_ the captive account. They do not
log into FAL as themselves.
Post by Dave Froble
Post by Simon Clubley
To stop this, you have to make absolutely 100% sure that network
mode access is blocked in the captive account. Apart from configuration
mistakes or omissions that might be made in this area, then for some
usage cases you simply cannot do that.
Makes me wonder if you actually use VMS ...
I suspect you are in one of those moods of yours where you sometimes
pretend not to understand anything in order to mess with people...
Post by Dave Froble
Post by Simon Clubley
Post by Dave Froble
What you're assuming is that a user already has these authorized
capabilities, and if so, then it is "authorized capabilities".
Well, that's a load of nonsense David.
No, that is exactly what we are discussing.
Any user can only do what they are authorized to do. They cannot access
any files they do not have access to. They cannot place files in any
directory they do not have access to.
Captive accounts are unique in VMS in that the user gets access to
an account with elevated privileges that you would never give them
normally if they had free access to the account.
Where did "elevated privileges" come from. Not for my captive users.
That's a different topic. I'm talking a user account with perhaps
TMPMBX and NETMBX.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Tad Winters
2021-05-12 20:49:46 UTC
Reply
Permalink
Post by Simon Clubley
Post by Dave Froble
Post by Stephen Hoffman
It's a way of directly activating hunks of a captive environment that
might not be accessible directly.
Only if those "hunks" exist.
As I have already mentioned, someone can also copy a command procedure
of their choosing to the captive account using FAL and then execute the
command procedure using one of the two methods.
Simon.
If you don't want that, set the ownership/protection on the command
procedure so that it cannot be overwritten.

Certainly you don't expect FAL to be implemented to determine if the
target file is a command procedure used as part of the potential group
of command procedures called from a CAPTIVE account, do you?
Simon Clubley
2021-05-13 04:14:35 UTC
Reply
Permalink
Post by Tad Winters
Post by Simon Clubley
Post by Dave Froble
Post by Stephen Hoffman
It's a way of directly activating hunks of a captive environment that
might not be accessible directly.
Only if those "hunks" exist.
As I have already mentioned, someone can also copy a command procedure
of their choosing to the captive account using FAL and then execute the
command procedure using one of the two methods.
Simon.
If you don't want that, set the ownership/protection on the command
procedure so that it cannot be overwritten.
But the attacker gets to create a filename of their own choosing.
They don't have to replace an existing command procedure because
both methods work on the attacker-chosen name, not an existing filename.

The point is that if they have network access, they can copy over
a filename of their choosing to the captive account and then execute
that file while still in network access mode, without ever having
to go anywhere near an interactive login in order to execute the
command file they have just transferred.
Post by Tad Winters
Certainly you don't expect FAL to be implemented to determine if the
target file is a command procedure used as part of the potential group
of command procedures called from a CAPTIVE account, do you?
No way. :-)

The real problem I have is with the active features of DECnet and that
they are enabled by default for captive accounts. To me, that violates
the principle of least astonishment:

https://en.wikipedia.org/wiki/Principle_of_least_astonishment

and VMS is supposed to be built around that principle.

What I would like to see is for FAL to go back to being the passive
data access mechanism by default that the specification says it should be.

I would also like to see the active features of DECnet (ie: task-to-task
communications) disabled by default for captive accounts until explicitly
enabled by the system manager.

If you protect the login command procedures sufficiently (along with
any associated data files) then the worst that can happen then if you
don't have things sufficiently locked down is that someone can write
passive junk into the captive account directory.

Network protocols need to be tightened up over time as new issues
are discovered. This happens to TCP/IP and it should happen to DECnet
as well. Just because something was once acceptable, does not mean it
is acceptable today.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Tad Winters
2021-05-13 05:06:06 UTC
Reply
Permalink
Post by Simon Clubley
Post by Tad Winters
Post by Simon Clubley
Post by Dave Froble
Post by Stephen Hoffman
It's a way of directly activating hunks of a captive environment that
might not be accessible directly.
Only if those "hunks" exist.
As I have already mentioned, someone can also copy a command procedure
of their choosing to the captive account using FAL and then execute the
command procedure using one of the two methods.
Simon.
If you don't want that, set the ownership/protection on the command
procedure so that it cannot be overwritten.
But the attacker gets to create a filename of their own choosing.
They don't have to replace an existing command procedure because
both methods work on the attacker-chosen name, not an existing filename.
The point is that if they have network access, they can copy over
a filename of their choosing to the captive account and then execute
that file while still in network access mode, without ever having
to go anywhere near an interactive login in order to execute the
command file they have just transferred.
Post by Tad Winters
Certainly you don't expect FAL to be implemented to determine if the
target file is a command procedure used as part of the potential group
of command procedures called from a CAPTIVE account, do you?
No way. :-)
The real problem I have is with the active features of DECnet and that
they are enabled by default for captive accounts. To me, that violates
https://en.wikipedia.org/wiki/Principle_of_least_astonishment
and VMS is supposed to be built around that principle.
What I would like to see is for FAL to go back to being the passive
data access mechanism by default that the specification says it should be.
I would also like to see the active features of DECnet (ie: task-to-task
communications) disabled by default for captive accounts until explicitly
enabled by the system manager.
If you protect the login command procedures sufficiently (along with
any associated data files) then the worst that can happen then if you
don't have things sufficiently locked down is that someone can write
passive junk into the captive account directory.
Network protocols need to be tightened up over time as new issues
are discovered. This happens to TCP/IP and it should happen to DECnet
as well. Just because something was once acceptable, does not mean it
is acceptable today.
Simon.
So you're saying that you want _one_ flag on a user account to not only
restrict interactive access to the defined login command procedure, but
to actually allow no other kinds of access? Perhaps the setting of that
flag should implicitly mark the account with /NOBATCH /NONETWORK
/NOREMOTE. Maybe you'd also like to use /PWDMINIMUM=30? Should
AUTHORIZE confirm the login command procedure exists and then SET
SECURITY/CLASS=FILE/PROTECTION=(WORLD) {the command procedure filename}?

Maybe AUTHORIZE should audit the content of the login command procedure
to make sure it will work as you intend. It will then also need to
translate SYS$SYLOGIN and audit that command procedure as well.

What else do you need it to do?
Simon Clubley
2021-05-13 12:13:26 UTC
Reply
Permalink
Post by Tad Winters
So you're saying that you want _one_ flag on a user account to not only
restrict interactive access to the defined login command procedure, but
to actually allow no other kinds of access? Perhaps the setting of that
No. Some way of leaving the passive network file access capabilities
active while disabling the active functionality by default.

As hard as it might be for some people around here to understand this,
security is a moving target and a design created several decades ago
might just possibly need changing to reflect modern security knowledge
and issues.
Post by Tad Winters
flag should implicitly mark the account with /NOBATCH /NONETWORK
/NOREMOTE. Maybe you'd also like to use /PWDMINIMUM=30? Should
AUTHORIZE confirm the login command procedure exists and then SET
SECURITY/CLASS=FILE/PROTECTION=(WORLD) {the command procedure filename}?
Maybe AUTHORIZE should audit the content of the login command procedure
to make sure it will work as you intend. It will then also need to
translate SYS$SYLOGIN and audit that command procedure as well.
What else do you need it to do?
People might think they are being clever with comments like this,
but in reality it just makes them look ossified.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-05-13 14:33:12 UTC
Reply
Permalink
Post by Simon Clubley
Post by Tad Winters
So you're saying that you want _one_ flag on a user account to not only
restrict interactive access to the defined login command procedure, but
to actually allow no other kinds of access? Perhaps the setting of that
No. Some way of leaving the passive network file access capabilities
active while disabling the active functionality by default.
As hard as it might be for some people around here to understand this,
security is a moving target and a design created several decades ago
might just possibly need changing to reflect modern security knowledge
and issues.
Post by Tad Winters
flag should implicitly mark the account with /NOBATCH /NONETWORK
/NOREMOTE. Maybe you'd also like to use /PWDMINIMUM=30? Should
AUTHORIZE confirm the login command procedure exists and then SET
SECURITY/CLASS=FILE/PROTECTION=(WORLD) {the command procedure filename}?
Maybe AUTHORIZE should audit the content of the login command procedure
to make sure it will work as you intend. It will then also need to
translate SYS$SYLOGIN and audit that command procedure as well.
What else do you need it to do?
People might think they are being clever with comments like this,
but in reality it just makes them look ossified.
Simon.
Perhaps it makes them appear knowledgeable and they realize how and why
to implement specific security, based upon real world requirements.

I'm not saying that everyone that ever managed a VMS system practiced
security, but many did, and do.

Most drivers keep their car on the road. If some don't, and end up
wrapped around a tree, is that the fault of the car? Perhaps today,
with self driving technology appearing, the car might avoid the trees,
but, just how new is that technology, and are we to scrap all cars
without it?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-05-13 17:22:08 UTC
Reply
Permalink
Post by Dave Froble
Most drivers keep their car on the road. If some don't, and end up
wrapped around a tree, is that the fault of the car? Perhaps today,
with self driving technology appearing, the car might avoid the trees,
but, just how new is that technology, and are we to scrap all cars
without it?
Yes, it actually _is_ limitations in the car if it's an older car they
are driving and they are seriously injured or killed in a crash as a result.

There's a reason why more modern cars have enhanced safety features
designed to help reduce the injuries to the driver if they do crash.

The same reasoning applies to operating systems as well.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-05-13 18:34:38 UTC
Reply
Permalink
Post by Simon Clubley
Post by Dave Froble
Most drivers keep their car on the road. If some don't, and end up
wrapped around a tree, is that the fault of the car? Perhaps today,
with self driving technology appearing, the car might avoid the trees,
but, just how new is that technology, and are we to scrap all cars
without it?
Yes, it actually _is_ limitations in the car if it's an older car they
are driving and they are seriously injured or killed in a crash as a result.
There's a reason why more modern cars have enhanced safety features
designed to help reduce the injuries to the driver if they do crash.
The same reasoning applies to operating systems as well.
Simon.
I have a hard time understanding why all people cannot see things the
same, when it's so fundamental. Such as just how wrong it is to chuck a
girl into a pit and start chucking rocks at her. But, it happens.

Simon, I'm starting to feel we could never agree on many things. From
my perspective, it's because you're unreasonable.

In my simple example, the topic of safety systems wasn't mentioned, and
is irrelevant. The issue was failure to drive safely. That has nothing
to do with the car, or safety equipment.

I ask again, are we to scrap all cars except maybe the current year's
models?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-05-13 18:47:51 UTC
Reply
Permalink
Post by Dave Froble
Post by Simon Clubley
Post by Dave Froble
Most drivers keep their car on the road. If some don't, and end up
wrapped around a tree, is that the fault of the car? Perhaps today,
with self driving technology appearing, the car might avoid the trees,
but, just how new is that technology, and are we to scrap all cars
without it?
Yes, it actually _is_ limitations in the car if it's an older car they
are driving and they are seriously injured or killed in a crash as a result.
There's a reason why more modern cars have enhanced safety features
designed to help reduce the injuries to the driver if they do crash.
The same reasoning applies to operating systems as well.
Simon.
I have a hard time understanding why all people cannot see things the
same, when it's so fundamental. Such as just how wrong it is to chuck a
girl into a pit and start chucking rocks at her. But, it happens.
I think you will find that thankfully any decent person agrees on that one.
Post by Dave Froble
Simon, I'm starting to feel we could never agree on many things. From
my perspective, it's because you're unreasonable.
No, it's because I look one or two steps ahead or because I look at
the implied issues about something instead of just looking at the
stated immediate issue.
Post by Dave Froble
In my simple example, the topic of safety systems wasn't mentioned, and
is irrelevant. The issue was failure to drive safely. That has nothing
to do with the car, or safety equipment.
I ask again, are we to scrap all cars except maybe the current year's
models?
People make mistakes. If they make a mistake while driving an older car,
then they are less protected in that case.

If only they, or the people who choose to drive with them, are affected,
that's a matter for them if they choose to drive an older car.

If other people can be harmed, then that's a matter for some regulation.

BTW, if people should be free to make their own decisions in these
matters when driving without regard to any regulation, then why do
parts of your country have mandatory chain laws for safety reasons ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Mark Berryman
2021-05-13 16:07:58 UTC
Reply
Permalink
Post by Simon Clubley
.
.
.
The point is that if they have network access, they can copy over
a filename of their choosing to the captive account and then execute
that file while still in network access mode, without ever having
to go anywhere near an interactive login in order to execute the
command file they have just transferred.
As I believe I have effectively demonstrated, no they can't. Why do you
continue to exist they can?

Mark Berryman
Simon Clubley
2021-05-13 17:58:57 UTC
Reply
Permalink
Post by Mark Berryman
Post by Simon Clubley
.
.
.
The point is that if they have network access, they can copy over
a filename of their choosing to the captive account and then execute
that file while still in network access mode, without ever having
to go anywhere near an interactive login in order to execute the
command file they have just transferred.
As I believe I have effectively demonstrated, no they can't. Why do you
continue to exist they can?
No you haven't Mark. There's no way in hell that you have even come
_close_ to demonstrating that.

All you have been able to demonstrate is that someone with detailed
knowledge of VMS (ie: you) and the time to experiment has been able
to implement something that addresses my concerns, and only by outright
denying network access to the captive account.

Now what about the average system manager or someone who has been given
some VMS systems to manage along with other systems but is not a VMS expert ?

What if they fail to write the perfect captive command procedure which
falls through instead of doing an explicit logout ?

What if they actually _do_ need to allow network access to the captive
account so files can be dropped into the account for later processing ?

In your worldview Mark, are these people solely responsible for any VMS
security issues simply because they didn't fully grasp the security
implications of some unknown to them concepts specific to VMS such as
task-to-task communications and remote batch submission ?

Did they even think about these concepts in the first place because the
documentation wasn't explicit enough about pointing out the security
implications of this functionality ?

In your worldview Mark, are they expected to read every single page
of the VMS documentation, eventually find the bit about SUBMIT/REMOTE
and then magically connect that to the captive account they setup ?

VMS should be secure by default and have multiple layers of protection
to help stop people from doing the wrong thing by mistake.

This is why I am annoyed with Doug's dismissive response. At a technical
level, he is correct. At a practical level, he is wrong because DECnet
should have some better controls than it currently does, with active
functionality disabled especially for captive accounts until explicitly
enabled by the system manager for an account.

So no Mark, you have not even come close to demonstrating that,
especially for systems which might be managed by people without the
level of knowledge that you have.

Simon.

PS: I wonder how many people have read my postings about this and
have then promptly gone off to check their captive account setups
in light of the active functionality I have highlighted ?

I wonder how many of them promptly found issues which they have now fixed ?

To those of you who did, you are welcome and I'm glad I could help.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-05-13 18:26:09 UTC
Reply
Permalink
Post by Simon Clubley
Post by Mark Berryman
Post by Simon Clubley
.
.
.
The point is that if they have network access, they can copy over
a filename of their choosing to the captive account and then execute
that file while still in network access mode, without ever having
to go anywhere near an interactive login in order to execute the
command file they have just transferred.
As I believe I have effectively demonstrated, no they can't. Why do you
continue to exist they can?
No you haven't Mark. There's no way in hell that you have even come
_close_ to demonstrating that.
All you have been able to demonstrate is that someone with detailed
knowledge of VMS (ie: you) and the time to experiment has been able
to implement something that addresses my concerns, and only by outright
denying network access to the captive account.
If a captive account needs network access, then something is very wrong
in the design of the apps and implementation.
Post by Simon Clubley
Now what about the average system manager or someone who has been given
some VMS systems to manage along with other systems but is not a VMS expert ?
Then they need to learn. Do you turn loose a driver on the road without
any training, or testing?
Post by Simon Clubley
What if they fail to write the perfect captive command procedure which
falls through instead of doing an explicit logout ?
If a captive user leaves the command procedure, the process is
terminated. No need to logout.
Post by Simon Clubley
What if they actually _do_ need to allow network access to the captive
account so files can be dropped into the account for later processing ?
Oh, no! Very poor app and installation design. If such happens, it
needs to be tightly controlled. No dumping data hither and yon.
Post by Simon Clubley
In your worldview Mark, are these people solely responsible for any VMS
security issues simply because they didn't fully grasp the security
implications of some unknown to them concepts specific to VMS such as
task-to-task communications and remote batch submission ?
Did they even think about these concepts in the first place because the
documentation wasn't explicit enough about pointing out the security
implications of this functionality ?
In your worldview Mark, are they expected to read every single page
of the VMS documentation,
If they don't, then why even write documentation? That is a major
problem with the Microsoft world.

If you don't know what you're doing, then hire someone who does.
OLtherwise, you deserve whatever your cheap ass gets.
Post by Simon Clubley
eventually find the bit about SUBMIT/REMOTE
and then magically connect that to the captive account they setup ?
When a captive user account is set up, properly setting up the SYSUAF
record is part of that setup.
Post by Simon Clubley
VMS should be secure by default and have multiple layers of protection
to help stop people from doing the wrong thing by mistake.
Ship it without a power cord ....
Post by Simon Clubley
This is why I am annoyed with Doug's dismissive response. At a technical
level, he is correct. At a practical level, he is wrong because DECnet
should have some better controls than it currently does, with active
functionality disabled especially for captive accounts until explicitly
enabled by the system manager for an account.
So no Mark, you have not even come close to demonstrating that,
especially for systems which might be managed by people without the
level of knowledge that you have.
Simon.
PS: I wonder how many people have read my postings about this and
have then promptly gone off to check their captive account setups
in light of the active functionality I have highlighted ?
I wonder how many of them promptly found issues which they have now fixed ?
To those of you who did, you are welcome and I'm glad I could help.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-05-13 18:36:18 UTC
Reply
Permalink
Post by Dave Froble
Post by Simon Clubley
Post by Mark Berryman
Post by Simon Clubley
.
.
.
The point is that if they have network access, they can copy over
a filename of their choosing to the captive account and then execute
that file while still in network access mode, without ever having
to go anywhere near an interactive login in order to execute the
command file they have just transferred.
As I believe I have effectively demonstrated, no they can't. Why do you
continue to exist they can?
No you haven't Mark. There's no way in hell that you have even come
_close_ to demonstrating that.
All you have been able to demonstrate is that someone with detailed
knowledge of VMS (ie: you) and the time to experiment has been able
to implement something that addresses my concerns, and only by outright
denying network access to the captive account.
If a captive account needs network access, then something is very wrong
in the design of the apps and implementation.
Post by Simon Clubley
Now what about the average system manager or someone who has been given
some VMS systems to manage along with other systems but is not a VMS expert ?
Then they need to learn. Do you turn loose a driver on the road without
any training, or testing?
VMS needs to be easier to manage in this day and age and to integrate
with the rest of the computing world or it is dead.
Post by Dave Froble
Post by Simon Clubley
What if they fail to write the perfect captive command procedure which
falls through instead of doing an explicit logout ?
If a captive user leaves the command procedure, the process is
terminated. No need to logout.
You are wrong, wrong, wrong about that in network mode!!!

In network mode, the network session continues if the captive command
procedure falls through, at least in my tests on VMS 8.4 Alpha and
VAX/VMS 7.3.

If you ever see the captive account - interactive access denied message
while using the captive command procedure in interactive mode then your
captive command procedure is not correctly written.
Post by Dave Froble
Post by Simon Clubley
What if they actually _do_ need to allow network access to the captive
account so files can be dropped into the account for later processing ?
Oh, no! Very poor app and installation design. If such happens, it
needs to be tightly controlled. No dumping data hither and yon.
Post by Simon Clubley
In your worldview Mark, are these people solely responsible for any VMS
security issues simply because they didn't fully grasp the security
implications of some unknown to them concepts specific to VMS such as
task-to-task communications and remote batch submission ?
Did they even think about these concepts in the first place because the
documentation wasn't explicit enough about pointing out the security
implications of this functionality ?
In your worldview Mark, are they expected to read every single page
of the VMS documentation,
If they don't, then why even write documentation? That is a major
problem with the Microsoft world.
Bloody hell David, you are making my point for me a _lot_ better than
even I can. :-(
Post by Dave Froble
If you don't know what you're doing, then hire someone who does.
OLtherwise, you deserve whatever your cheap ass gets.
Post by Simon Clubley
eventually find the bit about SUBMIT/REMOTE
and then magically connect that to the captive account they setup ?
When a captive user account is set up, properly setting up the SYSUAF
record is part of that setup.
Post by Simon Clubley
VMS should be secure by default and have multiple layers of protection
to help stop people from doing the wrong thing by mistake.
Ship it without a power cord ....
Seriously, David, seriously ? :-(
Post by Dave Froble
Post by Simon Clubley
This is why I am annoyed with Doug's dismissive response. At a technical
level, he is correct. At a practical level, he is wrong because DECnet
should have some better controls than it currently does, with active
functionality disabled especially for captive accounts until explicitly
enabled by the system manager for an account.
So no Mark, you have not even come close to demonstrating that,
especially for systems which might be managed by people without the
level of knowledge that you have.
Simon.
PS: I wonder how many people have read my postings about this and
have then promptly gone off to check their captive account setups
in light of the active functionality I have highlighted ?
I wonder how many of them promptly found issues which they have now fixed ?
To those of you who did, you are welcome and I'm glad I could help.
Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Stephen Hoffman
2021-05-13 19:05:22 UTC
Reply
Permalink
Post by Dave Froble
If a captive account needs network access, then something is very wrong
in the design of the apps and implementation.
I tend to use networking, mailboxes, and/or subsystem identifiers to
partition the unprivileged and the privileged activities.

So some apps do have NETMBX.

OpenVMS unfortunately doesn't have anything akin to XPC services, or
sandboxing, or pledge, so we end up creating our own—with the
trade-offs and risks inherent.
https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html


And this whole discussion is plunging toward discussions of app
sandboxing, an area where OpenVMS expects much and provides little.

And toward discussions of sandboxing and pledges that can restrict
where a given app can connect should that app be exploited, for
instance.

And of DCL networking, which is largely still stuck in the antediluvian era.
--
Pure Personal Opinion | HoffmanLabs LLC
Mark Berryman
2021-05-13 19:39:17 UTC
Reply
Permalink
Post by Simon Clubley
Post by Mark Berryman
Post by Simon Clubley
.
.
.
The point is that if they have network access, they can copy over
a filename of their choosing to the captive account and then execute
that file while still in network access mode, without ever having
to go anywhere near an interactive login in order to execute the
command file they have just transferred.
As I believe I have effectively demonstrated, no they can't. Why do you
continue to exist they can?
No you haven't Mark. There's no way in hell that you have even come
_close_ to demonstrating that.
All you have been able to demonstrate is that someone with detailed
knowledge of VMS (ie: you) and the time to experiment has been able
to implement something that addresses my concerns, and only by outright
denying network access to the captive account.
Wrong. I did not. There was no denying network access whatsoever.
Take a look at the posting again. There was also no experimenting. I
simply setup a captive login procedure with two lines in it and then
tried to access that account via FAL. It failed.
Post by Simon Clubley
Now what about the average system manager or someone who has been given
some VMS systems to manage along with other systems but is not a VMS expert ?
That is what the manuals are for. You've assumed that captive accounts
tend to be privileged, which is not a valid assumption. Setting up an
account with elevated access without reading the documentation is just
asking for trouble, regardless of the situation or the OS. (See most
Windows systems).

However, I think you will find that most captive accounts are setup so
that users need not learn the command line. They are given a nice menu
to do their work and they don't need to worry about how it is done.
Post by Simon Clubley
What if they fail to write the perfect captive command procedure which
falls through instead of doing an explicit logout ?
It such a case, the users get this error message:
%DCL-E-CAPTINT, captive account - interactive access denied

Along with a security audit.

Rather than constantly addressing the questions asked about that, the
logout gets added (yes, this is based on the input of multiple system
managers).
Post by Simon Clubley
What if they actually _do_ need to allow network access to the captive
account so files can be dropped into the account for later processing ?
That happens. *In every single case* where I have seen this done, the
files were dropped into a "dropbox" directory and did not use the
captive account directly, regardless of the skill level of the person
setting up the system.

In fact, every captive account I have seen (and I have seen many)
disallows inbound network access - again, regardless of the skill level
of the system manager. So maybe, regardless of the fact that this is
new to you, it is not a surprise to anyone else (at least, not to anyone
involved enough in a VMS system to be setting up a captive account).

As has been stated before, you've obviously never been responsible for a
captive account. Had you been, you likely would have already realized
that these issues get addressed.
Post by Simon Clubley
In your worldview Mark, are these people solely responsible for any VMS
security issues simply because they didn't fully grasp the security
implications of some unknown to them concepts specific to VMS such as
task-to-task communications and remote batch submission ?
Did they even think about these concepts in the first place because the
documentation wasn't explicit enough about pointing out the security
implications of this functionality ?
In your worldview Mark, are they expected to read every single page
of the VMS documentation, eventually find the bit about SUBMIT/REMOTE
and then magically connect that to the captive account they setup ?
Well, let's see. Way back when I was responsible for setting up some
captive accounts I was fairly new to VMS myself. I hadn't read all of
the VMS docs but I did make use of them for reference.

I was fully aware of submit/remote because it is clearly spelled out in
"DECnet for OpenVMS Guide to Networking". I was also aware of task to
task capabilities because it is also clearly spelled out in the same manual.

In *my* worldview, I don't put people ignorant of the system in charge
of the system. However, if that is the only option available, I do
expect them to make use of available resources to learn the system
before making changes to it.

As I said, I was once "ignorant of the system" myself. And yet,
somehow, none of my captive accounts were susceptible to the issue at
point here.

Let me be pointed.

Are there any captive accounts that don't take user input? If the
captive account is set up by someone with no idea of what they are doing
(i.e. they do take into account network, batch, etc.) then any attempt
to use FAL to talk to that account will result in FAL attempting to talk
to that user input, not its expected network object, and the FAL access
will fail.

If the captive account is set up to do some work and then quit without
ever getting any user input, then that account will do a logout (if for
no other reason than to prevent an error message and a security audit
every time it is used).

So, in what circumstance do you find this to be a genuine concern.
Post by Simon Clubley
VMS should be secure by default and have multiple layers of protection
to help stop people from doing the wrong thing by mistake.
You are welcome to resurrect SEVMS and find a way to make it viable
enough to be maintained moving forward. However, you will probably find
there are reasons that what you are asking for pretty much died on the vine.
Post by Simon Clubley
This is why I am annoyed with Doug's dismissive response. At a technical
level, he is correct. At a practical level, he is wrong because DECnet
should have some better controls than it currently does, with active
functionality disabled especially for captive accounts until explicitly
enabled by the system manager for an account.
So no Mark, you have not even come close to demonstrating that,
especially for systems which might be managed by people without the
level of knowledge that you have.
I believe I have. Show me where I haven't.

Mark
Simon Clubley
2021-05-14 12:37:20 UTC
Reply
Permalink
Post by Mark Berryman
Post by Simon Clubley
All you have been able to demonstrate is that someone with detailed
knowledge of VMS (ie: you) and the time to experiment has been able
to implement something that addresses my concerns, and only by outright
denying network access to the captive account.
Wrong. I did not. There was no denying network access whatsoever.
Yes, you did Mark. You used the f$mode() technique followed by an
explicit logout and that's an outright blocker for the modes you
want to deny. I've used the same technique myself in the past for
the same reason.
Post by Mark Berryman
As has been stated before, you've obviously never been responsible for a
captive account. Had you been, you likely would have already realized
that these issues get addressed.
You are wrong about that Mark. I have setup a number of captive accounts
in the past, including appropriate denials of mode access when required.

However, it's becoming obvious from reading this thread that my usage
cases for captive accounts in the past appears to be different from
what many others here are using them for.
Post by Mark Berryman
In *my* worldview, I don't put people ignorant of the system in charge
of the system. However, if that is the only option available, I do
expect them to make use of available resources to learn the system
before making changes to it.
Do you give them time to learn that stuff ? If so, then good for you
(seriously). It's clear from various postings here over the years that
not everyone is as lucky as that.
Post by Mark Berryman
Are there any captive accounts that don't take user input? If the
captive account is set up by someone with no idea of what they are doing
(i.e. they do take into account network, batch, etc.) then any attempt
to use FAL to talk to that account will result in FAL attempting to talk
to that user input, not its expected network object, and the FAL access
will fail.
That isn't what my experiments always revealed. I found cases where input
was prompted for and the input completed with an error, but the command
procedure fell through and the network mode session was maintained for FAL.
Post by Mark Berryman
Post by Simon Clubley
So no Mark, you have not even come close to demonstrating that,
especially for systems which might be managed by people without the
level of knowledge that you have.
I believe I have. Show me where I haven't.
People make mistakes Mark, especially people under pressure by managers
to get something done quickly.

Your argument is based around the fact that if people read all the
documentation and make the appropriate mental connections, they can
turn insecure defaults into a secure configuration.

That's not how it should work. There should be a limited secure
configuration by default and if you need to make it less secure
for some reason or need to enable active functionality, you are
_then_ forced to read the manuals to find out how to do that.

You should not be forced to read the manuals to find out how to turn
insecure defaults into secure ones.

In this very thread David has made the classic mistake of assuming that
it is safe to let a command procedure fall through because you will just
get logged out.

If _David_ can make that mistake even with all this documentation, then
what about the average person who doesn't have that level of knowledge ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-05-14 14:19:45 UTC
Reply
Permalink
Post by Simon Clubley
In this very thread David has made the classic mistake of assuming that
it is safe to let a command procedure fall through because you will just
get logged out.
If _David_ can make that mistake even with all this documentation, then
what about the average person who doesn't have that level of knowledge ?
Sure, blame it all on me ...
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Mark Berryman
2021-05-14 15:08:09 UTC
Reply
Permalink
Post by Simon Clubley
Post by Mark Berryman
Post by Simon Clubley
All you have been able to demonstrate is that someone with detailed
knowledge of VMS (ie: you) and the time to experiment has been able
to implement something that addresses my concerns, and only by outright
denying network access to the captive account.
Wrong. I did not. There was no denying network access whatsoever.
Yes, you did Mark. You used the f$mode() technique followed by an
explicit logout and that's an outright blocker for the modes you
want to deny. I've used the same technique myself in the past for
the same reason.
Quoting from my original posting, here are the contents of the captive
Post by Simon Clubley
$ logout
Mark
Simon Clubley
2021-05-14 17:35:28 UTC
Reply
Permalink
Post by Mark Berryman
Post by Simon Clubley
Post by Mark Berryman
Post by Simon Clubley
All you have been able to demonstrate is that someone with detailed
knowledge of VMS (ie: you) and the time to experiment has been able
to implement something that addresses my concerns, and only by outright
denying network access to the captive account.
Wrong. I did not. There was no denying network access whatsoever.
Yes, you did Mark. You used the f$mode() technique followed by an
explicit logout and that's an outright blocker for the modes you
want to deny. I've used the same technique myself in the past for
the same reason.
Quoting from my original posting, here are the contents of the captive
Post by Simon Clubley
$ logout
That's from your first example Mark which also outright denies
access to network mode by means of the logout statement without
even checking any modes.

Your second example, which does use f$mode(), and is a better way
to achieve this, also outright denies access to network mode, but
in a more controlled way.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Tad Winters
2021-05-15 03:20:17 UTC
Reply
Permalink
Post by Simon Clubley
Post by Mark Berryman
Post by Simon Clubley
Post by Mark Berryman
Post by Simon Clubley
All you have been able to demonstrate is that someone with detailed
knowledge of VMS (ie: you) and the time to experiment has been able
to implement something that addresses my concerns, and only by outright
denying network access to the captive account.
Wrong. I did not. There was no denying network access whatsoever.
Yes, you did Mark. You used the f$mode() technique followed by an
explicit logout and that's an outright blocker for the modes you
want to deny. I've used the same technique myself in the past for
the same reason.
Quoting from my original posting, here are the contents of the captive
Post by Simon Clubley
$ logout
That's from your first example Mark which also outright denies
access to network mode by means of the logout statement without
even checking any modes.
Your second example, which does use f$mode(), and is a better way
to achieve this, also outright denies access to network mode, but
in a more controlled way.
Simon.
I used f$mode() long before I made a CAPTIVE account. In fact,
management, at multiple companies, didn't know enough to even ask for
such accounts. The last company at which I implemented CAPTIVE
accounts, I was asked to give some "help desk" people the ability to
create accounts for others. _I_ chose how to implement this. _I_
decided on how to limit them. _I_ locked them into a menu that allowed
them to enter the new user's full name, then my command procedure found
an unused member number of the only group to which they could be added,
and created a username based on the entered full name, but unique. The
procedure then creates the account and displays the full output from
AUTHORIZE. They then get to select to accept it or not. If they do not
accept it, it is deleted. If it is accepted, the user directory is
created with the correct owner and protection mask, the appropriate
login command procedure is put in place, and likely some other items
were set up. The "help desk" users also set application permissions
through the same menu. Since I created that setup more than 15 years
ago, it's hard to remember all the details, but I had it tightly locked
down.
The interesting thing is that there was no one known to me in that
company that had near the knowledge of the operating system, but not
because they didn't have as much time to learn about it. Rather, they
didn't have the interest. They were more concerned about the business,
and ultimately they finished their transition to Windows.
They have not managed to always keep Windows secure. There were many
Windows Administrators. VMS was not exploited during my tenure.

One thing I will say about management, is that they will demand lower
security when it suits their purposes. I did work for a company where
the management insisted they wanted the VMS password minimum length to
be four (4) characters. Ouch. Fortunately, it was behind a firewall.
Still, the VMS system wasn't compromised. I don't know about their
other systems.

In the end, I was a programmer who was interested in making best use of
the operating system, in a shared way. I was interested in the
operating system features. I explored it and read about it. The
president of the software company, where I worked, subscribed to DEC
Professional, and I read every issue I found. In fact, I took every
issue home, when they were throwing them out. I think I still have
them. So you see, it was not that I needed special training paid for by
my employer, though I sure wish I could have attended a DEC Symposium,
but I just wanted to know. Unfortunately, I never had opportunity to
create a cluster with VMS.
Arne Vajhøj
2021-05-17 18:51:57 UTC
Reply
Permalink
Post by Simon Clubley
Post by Mark Berryman
Post by Simon Clubley
Post by Mark Berryman
Post by Simon Clubley
All you have been able to demonstrate is that someone with detailed
knowledge of VMS (ie: you) and the time to experiment has been able
to implement something that addresses my concerns, and only by outright
denying network access to the captive account.
Wrong. I did not. There was no denying network access whatsoever.
Yes, you did Mark. You used the f$mode() technique followed by an
explicit logout and that's an outright blocker for the modes you
want to deny. I've used the same technique myself in the past for
the same reason.
Quoting from my original posting, here are the contents of the captive
Post by Simon Clubley
$ logout
That's from your first example Mark which also outright denies
access to network mode by means of the logout statement without
even checking any modes.
Your second example, which does use f$mode(), and is a better way
to achieve this, also outright denies access to network mode, but
in a more controlled way.
The examples have something in common: they are both shown
in the examples in the manual.

Arne
Loading...