Jeff Kell ([log in to unmask]) wrote:
 
<snip>
 
: Now that I've set the stage (doesn't everybody like a mystery?)...
 
: If you attempt to :RENAME a file and you are NOT the creator, you no longer
: get the old "user not creator" or whatever error (sorry, don't have a non-5.0
: system to get the message from!), but instead you get:
 
: > USER LACKS DELETE DIRECTORY (DD) ACCESS (FSERR 462)
: > RENAME failed due to file system error.  Not renamed. (CIERR 373)
 
: And presto, the file now has the $OWNER-restricted ACD attached.
 
I'm doing this from memory.  So, don't shoot me if I'm not totally correct.
There was a defect involving :RENAME that a failed command (or intrinsic)
might leave the file with an ACD on it.  I don't remember what release the
problem was introduced or fixed in, but it sounds about right that 5.0 Pull
would have the defect in it.  I thought this defect was supposed to be
documented with one of the materials users receieve with the release...
I guess not.
 
BUT, this isn't the major reason I'm responding to this post.  It is possible
doing :RENAMEs strictly within MPE groups to cause an ACD to be placed on a
file.  This happens whenever the user doing the :RENAME is not a privileged
user (SM, AM, or creator) with respect to the file.  Because we removed the
creator-only restiction from RENAME on 5.0, such a user could rename a file.
In this case, a RENAME from one MPE group to another MPE group will cause an
ACD to be put on the file.  This ACD attempts to preserve the file's original
security as much as possible.  However, GU, GL, and AL access information
will be lost...because they can't be represented in an ACD.
 
Now, why did we do this?  If you want a challenge, try to answer this for
yourself before reading on.
 
Let's say you've been granted WRITE access to a log file of some sort, but
you don't have READ access.  Also, you're not the creator, SM, or AM.  You'd
be able to purge this file, but not read it's contents.  Now, lets say you
have SAVE and READ access to your home group.  With the new RENAME behavior,
you can :RENAME this log file from its current MPE group into your home group
and gain READ access to the file.  This is a NoNo!  [You can do this because
you are able to purge the file from its original group and you can create
files in your home group.  That's all RENAME requires in order to rename a
file starting in 4.5.]
 
So, we invented a rule that says if a non-creator, non-SM, and non-AM user
successfully renames a file from one MPE group to another, then an ACD is
added to the file that preserves the file's original security as much as
possible.  The rule doesn't apply to the creator because the creator is
allowed to modify the security on a file.  The same argument applies to
SM and AM users.
 
Mike P.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Mike Paivinen
[log in to unmask]
 
Hewlett-Packard
CSY - Mailstop 47UP
19447 Pruneridge Avenue
Cupertino, CA   95014