Jeff Kell ([log in to unmask]) wrote:
: Prior to 5.0 (4.5?) if you tried to :RENAME a file and you weren't the file
: creator, you got an error message and that was it; provided you had read and
: write access to the original file, you could then :COPY it to the new file
: and :PURGE the old one.  No big deal, either it worked, or you worked around.
 
: As of 5.0 this changes.  If you have read/write access to the original file,
: it makes an effort to allow you to rename the file (since you could anyway)
: but tries to set an ACD to allow access to the original owner of the file.
: But this is a "not yet ready for prime-time" routine, and while it succeeds
: in the initial setting of the new ACD, it fails to rename the file (since
: you aren't the creator).  The original file is left with this cryptic ACD
: in place and you essentially have no access to the file.
 
Jeff is correct in describing a defect present in MPE/iX affecting users who
:RENAME a file but aren't the creator, AM or SM.  However, the ACD is put on
so a user can't gain additional access to a file by renaming it.  This behavior
can cause a user to lose access to a file even when the :RENAME is
successful.  (The defect described by Jeff causes a problem when the :RENAME
fails.)
 
What security hole were we trying to fix?  First, the creator of a file, a
user who is AM for the file, and a user with SM capability can always change
the security of a file by putting an ACD on the file.  (Sooner or later,
they'll be able to use ALTSEC (ACCESS=), SECURE, and RELEASE.  These commands
are still restricted to the creator.)  If one of these users renames a file
from one MPE group to another MPE group in the same account, no ACD is put on
the file.  However, other users are allowed to do the very same :RENAME
starting with MPE/iX Release 4.5.  As long as a user has WRITE access to the
file and SAVE access to the new group, they can :RENAME the file.  A
potential security problem occurs when a file grants READ access to GU users
and WRITE access to AC users, for example, a log file.  A non-GU user can
:RENAME this file into their home group -- they have WRITE access to the file
and presumably SAVE acces to their home group.  By doing the :RENAME, the user
now has READ access to the file.  (This assumes that most users have READ
access to files in their home group.)  To prevent this user from gaining
additional access to the file, MPE/iX puts an ACD on the file.  The rule is:
 
   When a user other than the creator/AM/SM renames a file from one
   MPE group to another MPE group in the same account, MPE/iX puts an ACD
   on the file.  The ACD attempts to maintain the same security that the
   file had in its original location.
 
What's the problem?  The problem is in the phrase "attempts to".  Although
ACDs are generally more expressive than matrix security -- you can grant/deny
access to an individual user, an ACD cannot express the user classes GU, AL,
or GL.  The end result of the rename may be that the user doing the rename
loses access to the file.  For example, if a file grants READ/WRITE access
to GU users only, then any user that can log on into the file's MPE group can
rename the file into their home group.  If the user isn't the creator/AM/SM,
MPE/iX will put an ACD on the file.  However, GU can't be expressed in the
ACD.  So, the end result is that the user will no longer have READ/WRITE access
to this file.
 
Unfortunately, the bug described by Jeff prevents you from trying this out
for yourself.  Why?  Because the ACD is put on the file at the very
beginning of FRENAME()...before we do the security check.  As described in
"What's the problem?", the ACD may take away access the user was originally
granted.  If WRITE access is taken away, as in the above example, the :RENAME
fails.  Not only that, but another defect leaves the ACD on the file.  Now,
even though the :RENAME failed, the user has lost access to the file.  In
some sense, this demonstrates the behavior described in "What's the problem?"
because this is the same ACD that would be on the file even if the :RENAME
succeeded.
 
To test your comprehension of the effect that :RENAME has on a file's
security, try the following exercise.  (This exercise can be attempted even
with the MPE/iX defects described above.)  Create a file and alter it's
security
so that a non-privileged user (not the creator) can successfully :RENAME the
file from one MPE group to another MPE group in the same account, but the user
loses some form of access to the file after the successful :RENAME.
 
If you still have questions after reading my overly-length prose (several
times :) and trying the exercise, please post your question here or e-mail me.
I'll be happy to clarify whatever I've muddled up.
 
Mike P.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Mike Paivinen
[log in to unmask]
 
Hewlett-Packard
CSY - Mailstop 47UP
19447 Pruneridge Avenue
Cupertino, CA   95014