MPE file security is an interesting sort of thing. It is powerful enough to cause a lot of confusion -- what's the difference between :ALTSEC, :RELEASE, and :SECURE? What do R, A, W, L, X, ANY, AC, AL, GU, GL, and CR mean? How do file, group, and account security work? Unfortunately, it's not powerful enough to do a lot of things that you'd very much like to do (such as grant a particular access to a particular user id). If it were only a little bit less fancy or a little bit more fancy, life would be a lot easier...
First, a little general discussion. From the file system's point of view, there are five types of access you can have to a file:
* READ -- if you have READ access to a file, you can open the file and read data from it. Simple.
* APPEND -- if you have APPEND access to a file, you can open the file and add records to it. You can't read records (unless you also have READ access) or overwrite them or purge the file (unless you also have WRITE access).
* WRITE -- if you have WRITE access to a file, you can open the file, append records to it, overwriting existing records, or purge the file; you can't read records unless you also have READ access. Note that if you have WRITE access, you will always be allowed to :PURGE the file -- you can't grant a user write access and deny him purge access.
* LOCK -- if you have LOCK access to a file, you can open it EXCLUSIVELY and/or open it shared but then call the FLOCK intrinsic. Lock access doesn't explicitly imply read or write (though it would be pretty useless if you didn't also have read or write access to a file); note, however, that APPEND and WRITE access DO imply LOCK access -- if you have append/write access to a file, you can always open it exclusively or FLOCK it even if you don't have lock access to it.
* EXECUTE -- if you have EXECUTE access to a program file, you can
run it; if you have EXECUTE access to a job stream file, you can
:STREAM it. You don't need any other access to do these things --
thus, you may deny a user READ access to a program or job stream
and still let him run it or :STREAM it.
You should remember these "access types" because they control what you may or may not do with file security. For instance, as I mentioned, the fact that there is no special "PURGE" access mode means that you can't allow writes but forbids :PURGEs; however, since there IS a special "APPEND" mode you can allow appending to a file (e.g. some sort of log file) but not allow overwriting.
Now that we've discussed HOW a file may be accessed, we must ask WHO it can be accessed by. Say that you've built a file and want to grant READ and APPEND access to certain people -- how do you do this?
Well, for every type of access (Read, Append, Write, Lock, and Execute, abbreviated R, A, W, L, and X), you may specify a set of "user class specifiers". You may say that the particular access involved is allowed to:
* ANY, meaning any user in the system;
* AC, meaning any user in the account in which the file resides;
* GU, meaning any user who signs on to the group in which the file resides;
* CR, meaning only the user who created the file;
* AL, meaning any user with AL ("Account Librarian") capability in the account in which the file resides;
* GL, meaning any user with GL ("Group Librarian") capability who signs on to the group in which the file resides;
* Any combination of the above;
* None of the above, in which case access is allowed only to a user with SM (System Manager) capability or a user with AM (Account Manager) capability in the file's account. An SM or AM user can ALWAYS do ANYTHING to a file.
Thus, when you say
you mean "anybody can Read or Append to the file F, but only the file's creator can Write to it, Lock it, or Execute it". Similarly, when you say:
you mean "anybody in the account can Execute the file, only users with AL capability can Read it or Lock it, and only users in the file's group can Write to it or Append to it".
So, thus far we've discussed HOW a file may be accessed and WHO you can allow to access it. Note that one thing conspicuously missing from our discussion is the ability to say "user JOE can read the file and user JOHN can write to it". This is because MPE provides no such ability. Unless you can arrange the right capabilities (SM, AM, AL, or GL) for the right users, you can't really control access by individual user id.
One other important fact, however (which substantially changes the implications of what we've talked about), has to do with GROUP and ACCOUNT security. Just as you can restrict R, A, W, L, and X access on an individual file, you can also restrict it on a group (which means that the restriction applies to all the files in the group) or on an account (which means that the restriction applies to all the files in the account). In order to access a file, a user must satisfy the file restrictions AND the group restrictions AND the account restrictions. For instance, say that we say:
:ALTACCT PROD;ACCESS= (R,X:ANY; W,A,L:AC) :ALTGROUP DATA.PROD;ACCESS= (R:ANY; X:AC; A:GU,AL; W:GU; L:CR) :ALTSEC F.DATA.PROD;ACCESS= (R:CR; X:ANY; A:AC; W:CR,GU; L:AL)
What are the true access restrictions on F.DATA.PROD? We must COMBINE -- "AND" together -- all three sets of restrictions:
Access Account Group File Total R ANY ANY CR CR A AC GU or AL AC GU or AL W AC GU CR or GU GU L AC CR AL CR X ANY AC ANY AC
As you see, the resultant access rights are as restrictive as the account, group, and file access rights put together. Even though account and group security allows anybody to read the file, file security allows only the CReator to read it -- therefore, only the creator may read it; even though account and file security let anybody execute the file, group security allows only ACcount users to execute it -- therefore, only users in the PROD account can execute it.
Now, we have the theory down; let's have a look at the practice. By default, all accounts (except the SYS) account have access restrictions of
In other words, by default NOBODY outside an account can access a file in the account, EVEN IF FILE AND GROUP SECURITY ALLOW IT! Similarly, all groups (except PUB groups in any account) by default have access restrictions of
Thus, NOBODY outside a group can access a file in the group, EVEN IF FILE AND ACCOUNT SECURITY ALLOW IT! On the other hand, default file security is
Access is allowed to anybody in the system who can pass the group and account restrictions, but as we just saw, with default restrictions this means that only a user in the file's group can access the file in any way!
You can see the serious problems that this causes. Say that I am JOHN.PROD and I want to let MARY.DEV read my file. First of all, I can't just allow MARY.DEV read it (since access rights can only be given to classes of users, such as ANY, not to individual user ids). However, say that I'm willing to let everybody read the file -- I still can't do this! For MARY.DEV to read my file, she must be able to pass file security (which is easy, since by default it is R:ANY), but also group and account security, which by default prohibit any access! To let MARY.DEV read my file, I have to:
* Go to my account manager and ask him to grant Read access to ANY on the group in which the file resides;
* Go to my system manager and ask him to grant Read access to ANY on the account in which the file resides;
Now, after I've gotten two other people involved in this, ALL files in the group in question are readable by ANYBODY (unless I explicitly :ALTSEC all those files to lower their file security, which [even with MPEX] may be a cumbersome task). I've had to spend a lot of effort, and in the bargain have waived security on a lot more than what I wanted to waive it on.
Thus, we see several problems with file security:
* You can't grant access to an individual user id, only to an entire class of users.
* Default group and account security is such that a normal user must intervene with his Account Manager AND his System Manager to let people access one of his files.
* In the process of granting access to a file, the AM and SM must lower security on the account and the group, THUS WAIVING SECURITY ON ALL THE FILES IN THE GROUP.
* Finally (one thing we hadn't mentioned before), file-level security (implemented using :ALTSEC) is very hard to maintain since whenever you /KEEP the file in EDITOR, the file security is RESET to (R,A,W,L,X:ANY)! Thus, if you leave your group and account security open and rely on :ALTSEC to protect your files, you must make sure that EVERY TIME YOU DO AN EDITOR /KEEP (or re-build the file in any other way), YOU REPEAT THE :ALTSEC COMMAND. If you don't, you'll leave the file wide open.
:RELEASEing FILES -- WHY IT'S BAD, WHY PEOPLE DO IT, WHEN IT'S OK
Therefore, on the one hand we have far too much security -- group and account security gets in the way. On the other hand, we don't have enough security, since once we waive group and account security, we leave ourselves wide open. To avoid these problems, HP invented the :RELEASE and :SECURE commands, but these have very substantial problems all their own.
Simply put, :RELEASEing a file allows ANYBODY to do ANYTHING to the file. ANY USER ON THE SYSTEM can READ the file, WRITE to it, APPEND to it, LOCK it, EXECUTE it, PURGE it, do whatever he pleases to it. The advantage of this is you can let MARY.DEV read your file without having to change group/account security (since :RELEASE waives ALL security, file, group, and account); the disadvantage is that not only can MARY.DEV read it, but she can also modify it or purge it, AS CAN EVERYBODY ELSE IN THE SYSTEM. Again, you either have too much security (nobody can do anything) or far too much (everybody can do everything).
Unfortunately, the dangers of :RELEASE go way beyond the danger to the now-unsecured file. In particular, if you have A GROUP WITH PM CAPABILITY and you :RELEASE a PROGRAM FILE that resides in that group, then an ordinary, plain vanilla user can OBTAIN SM OR AM CAPABILITY. Naturally, I won't explain exactly how he'll do this, but trust me -- :RELEASEing program files in groups with PM capability (the program itself need not necessarily have PM) is A VERY BAD IDEA. We suggest to our MPEX users that every night they execute the command
:RUN MPEX.PUB.VESOFT %SECURE @.@.@ (CODE="PROG" and ISRELEASED and GPMCAP=ON)
which will find all the program files (CODE="PROG") that are :RELEASEd (SECURITY=OFF) and reside in privileged groups (GPMCAP=ON) and :SECURE them. If you don't do this -- if you let such files to stay on your system -- you can be extremely vulnerable to break-ins.
I personally think that virtually every :RELEASE is a bad idea, since it's very rare that you really want to let ANYBODY do ANYTHING to a file. What you ought to do instead is organize your file security in such a way that it's easy for people to selectively grant appropriate access to other people -- this isn't very simple to do, but I'll give a fairly straightforward recipe shortly. The only other thing that ought to be said about :RELEASE is that IT'S OK TO RELEASE DATABASES (using DBUTIL or MPEX). Since databases are protected from normal file system access by their PRIV file code, and since IMAGE security implements an additional layer of security on top of normal file system security, you can afford to release them. That way, file security will be entirely bypassed and the user will only have to specify the right IMAGE password to be able to access the database.
STRUCTURING YOUR SYSTEM SECURITY TO AVOID :RELEASEs
We've established that :RELEASEing files is generally not a good thing to do. Unfortunately, with a default security set-up, :RELEASEs are often necessary (the only other alternative being to get BOTH your account manager AND your system manager involved, and then risk the security of other files by changing group and account security). The only way you can really avoid :RELEASEs is by making easier the legitimate things that people may want to do -- allow other people to read and/or write their files.
The first step is to :ALTACCT ALL YOUR ACCOUNTS TO HAVE (R,A,W,L,X:ANY). Is this a safe thing to do? Yes, because group security (by default (R,A,W,L,X:GU)) can protect your files perfectly well. The only thing you might be concerned about is that default security for PUB groups is (R,X:ANY;A,W,L,S:AL,GU); thus, the above :ALTACCT read and execute files in your PUB groups. This is probably not a problem (that's usually what PUB groups are for), but if it is, you can just :ALTGROUP your PUB group to deny R or X access (or BOTH) to non-AC users.
Now that your account security is waived, you can control file security by groups. I recommend that you build a group in each account called READANY:
As you see, anybody can Read or Execute files in this group, but only the file's creator can modify them. Say that I want to let MARY.DEV read that file of mine -- all I need to do is say:
Now Mary can read MYFILE but she can't modify it (since the file has W access allowed only to me, the file's creator). Alternatively, I might decide that anybody should be able to read all of my files -- I can then just go to my account manager and ask him to change my group security, without having to get the system manager involved. Then I could, if I want to, further control my file security by using :ALTSECs, but it's unlikely that I will, since file security gets so easily lost every time a file is re-built (e.g. in an EDITOR /KEEP or a re-:PREP of a program file).
Further, if you care about security within accounts, you might well have a group called READAC:
Any file that I want to "show" to some other user in my account can just be moved to the READAC group -- it will then be readable to all account users, but to no users (except those with SM) in other accounts.
Go to Adager's index of technical papers ⮂ View original 1980s typography