Michael Anderson ([log in to unmask]) wrote:
: OTOH, the access timestamp should be updated, another POSIX command falling
: just short of the mark.

In this regard, the mv command is different, not wrong.  The RENAME command
opens the file.  Therefore, the access time changes.  The 'mv' command doesn't
open the file; so, the access time stamp isn't changed.  From my point of
view, one isn't right or wrong.  They're just different.

: Also the "mv" command in POSIX doesn't care if you are the CREATOR of the
: file, As long as file permissions (ACD's) are setup a particular way, or you
: have "SM" capability.

RENAME and 'mv' have exactly the same security rules for who can "rename"
a file -- you need CD access to the new location and DD access to the
old location.

: I'm thinking maybe that using POSIX commands to get around MPE rules maybe
: the first step to losing the MISSION CRITICAL ATTITUDE  that MPE has always
: had. I am sure that MPE's rules have a purpose and should NOT be
: side-stepped. However it's nice, after you have analyzed all the factors
: involved (make sure you know when you don't know) and decided that you really
: need to side-step an MPE rule, that in some cases POSIX will allow it.

As far as I'm aware [and we designed it this way], there are no POSIX functions
that violate MPE security rules ... and I include unlink() in this category.
You can't unlink() a file that you couldn't remove via an FOPEN/FCLOSE(delete)
sequence.  The same security check is done in both cases.  unlink() provides
an immediate result that FOPEN/FCLOSE doesn't.  So, yes, POSIX is different
in some of its behaviors, but it doesn't provide backdoors to MPE security.
[Perhaps this is a semantic argument rather than one of substance; I'm not
sure.]

Mike P.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Mike Paivinen
[log in to unmask]

Hewlett-Packard
CSY - Mailstop 47UA
19447 Pruneridge Avenue
Cupertino, CA   95014