by Eugene Volokh, VESOFT

   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.

                        WHO CAN ACCESS A FILE?

   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

   * 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:


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

   (R, A, W, X, L: AC)

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

   (R, A, W, X, L: GU)

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

   (R, A, W, X, L: ANY)

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

   *  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.


   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

   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


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.


   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

Go to Adager's index of technical papers