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