VMS- Read only User Account?

[shrloc]

We have a three node cluster. V8.3-1h1. Two nodes are production and one is being modified for use as a development only node. Nodes A and B have their own “disk1: and disk2: (volume label User_1 and User_2”, that only A and B can see. Node C also has its own “disk1: and disk2: (Volume label Dev_1 and Dev_2)” that only C can see. All nodes have access to “disk3: (volume label User_3). The files on Node C are copies of those on Node A and B.

Nodes A and B use one SYSUAF and Node C uses its own. The developers only have active accounts in the Node C SYSUAF and the Users only have accounts in the one being used by Nodes A and B.

What we would like to be able to do is use something like WS-FTP to allow developers to get the most recent files off one of the other nodes and bring it to the development Node, but not be able to write back. In other words: FTP files from Node A or B to Node C, but not the other way (Node C to Node A or B). The programmers have to be able to touch any file in any user directory.

My plan had been to create a User account that could only read and not write. I created a restricted account in Node C’s SYSUAF with authorized and default privileges of NETMBX, READALL and TMPMBX and a LOCKPWD flag. I set up an identical user account in the SYSUAF for Nodes A and B. The thought was that the programmers could then use the accounts to connect to the Nodes with WS-FTP and move the files from production to development, but not back again.

After testing I find that the transfer can happen in both directions.

Our goal is to prevent programmers from placing modified files back on the production Nodes without going through the Project and System Managers’ review. Once approved the System Manager would then place the files onto the production Nodes.

I am open to any suggestions.

[Hoff]

1: you should have your production files under source code control.

1a: That means you can rebuild your configuration.
1b: you have change control and change tracking
1c: you can revert.
1d: you can easily use (for instance) Mercurial (Hg) to pull the files to a development system.

2: you should not have developers loose in the production environment.

2a: developers make changes, and (with simple errors) that can render production unstable.

2b: it is fairly common practice to have a completely separate development cluster, so that (for instance) locks don't collide and developers running with privilege don't (for instance) nuke the wrong files.


3: multiple SYSUAF files within a cluster requires UIC coordination, or unexpected access or unexpected access denials can arise.


Now as for your question, that's easy. Create a user that has an identifier granted that allows (only) read access to the target files, and add that identifier to ACLs on the files and directories you're interested in in your production pool. That'll involve creating the identifier, granting it to the ftp user or (since you're in a cluster, you needn't use ftp or DECnet FAL at all) just grant the identifier to the developers and let them go directly at production area (for read).

See the OpenVMS system security manual for details on ACLs and identifiers.

[Andy Bustamante]

Given that you're already in a cluster environment, mount the source disk on Node C and grant read only access to your developers to the appropriate directories. skip the issues with FTP and simply copy file.

One of the advantages to a cluster is a single SYSUAF and RIGHTSLIST files. Seriously consider merging these.

[Shriniketan Bhagwat]

Hi,

How about alocating ACls for files on node A and B. Refere the chapter System security services from Open VMS programming concepts manual, Volume 2 for more details.

Regards,
Ketan

[Robert Gezelter]

shrloc,

There are better ways to do this. The cleanest is to properly protect the files, and then it does not matter if it is on the same disk.

If there are political issues, then I would agree with Andy: Mount the disk /NOWRITE on the development machine. However, as noted, this is not necessary unless the files are:
- not ACL'ed correctly
- the developers have privileges (in which nothing short of a separate copy will work in any event).

- Bob Gezelter, http://www.rlgsc.com

[shrloc]

One thing I should have noted it that the progammers are only allowed to log on to the node C. Everyone else logs on to the other noded via load balancing.

Also these system was well establed before I got here and the Manager who created it did not use ACL or bother to establish unique UICs. (I can hear the collective gasp).

[Hoff]

And if you go the ACL route as all three previous posts suggest, you must also coordinate the identifier values across your two lobes of this cluster. Which you should do anyway. This in addition to coordinating the user UIC values.

if you don't coordinate these values, you can and often will get unexpected denials or unexpected access.

If you want to clean off all of the ACLs on a target device (which can be part of merging a cluster, or when otherwise resolving disparate identifiers), I've posted a tool here:

http://labs.hoffmanlabs./com/node/426

[Jan van den Ende]

shrloc.

>>>
... it did not use ACL or bother to establish unique UICs.
<<<
Firsth thing: CORRECT THIS!!!

And then:

DO take the other suggestions:

- make well-considered identifiers & rights for them
- MERGE (but with proper safeguards!) SYSUAF & RIGHTSLIST.
- (if you still feel the need) rstrict the develloppers to node-c. (straight-forward DECnet-access, or well-chosen FTP-(or similar)-alias.
Prevent any devellopment activity access with (nodename based, special IDENT based?) ACLs.
Been there, done that. 1% inspiration or copying ideas), 99% just plain, simple work.

hth

Proost.

Have one on me.

jpe

[John Gillings]

shrloc,

>created a restricted account in Node Câ s
>SYSUAF with authorized and default
>privileges of NETMBX, READALL and TMPMBX
>and a LOCKPWD flag

It's not entirely clear... are you allowing these "restricted" users to login to a DCL prompt? If so, remember that READALL is a class ALL privilege. It's actually misnamed, it should be called READANDCONTROLALL. That means READALL can trivially be converted into any privilege, so such users are definitely NOT restricted. Even in a CAPTIVE account, READALL can be tricky to pin down.

Having multiple SYSUAFs in a single cluster is a very, very BAD idea. Unless you have very tight coordination between changes across SYSUAFs, you have a significant potential to create "invisible" security holes.

Rather than tinkering with suggestions from strangers, I would STRONGLY recommend you sit down and read the Guide to OpenVMS System Security and design a workable security model for your system that satisfies all your requirements and minimises risks.

This is not something you can do with a wave of a magic command. You need to plan it carefully. If in doubt, hire a consultant with experience in the field.

[P Muralidhar Kini]

Hi Shrloc,

>> What we would like to be able to do is use something like WS-FTP to allow
>> developers to get the most recent files off one of the other nodes and bring
>> it to the development Node, but not be able to write back.

* MOUNT/NOWRITE on Node C
The disk can be mounted on the Node C with /NOWRITE qualifier.
The developers who log in to Node C will now be able to access the contents
of the disk. Because the disk is mounted "/NOWRITE", they would have only
read access to the disk and not write access.

Note that the entire disk would be available for Read access. If your original
plan was to share only directories "A" and "B" then this method may not be
suited. This is because as the disk is mounted with "/NOWRITE", the users on
Node C would have read access to all files/directories on the disk.

* User Account on NODE A/B with Read Access
User accounts would be created in Node A/B with limited access to limited
directories.

In this case, if your original plan was to shared only say directories "A" and "B"
then you can make use of the ACL's to have the user get access only to
directories "A" and "B". I guess this would be more suited to you.

Check the "OpenVMS Guide to System Security" Manual for more information
on the rights Identifier and ACL's.

Regards,
Murali