NT blaming an NTFS Flaw on POSIX?

LordXarph was skimming through the book "Microsoft Windows NT Network Administration" he came across a passage claiming that a strange piece of behavior under NT (it could be even called a bug) was due to its compliance to POSIX rules. Now I don't know whether the problem is true or not, but I was hoping someone well versed in NT and POSIX systems might answer his question instead. Click below for more.

"Ok, Whilst skimming through the book I came across the following passage:

PROBLEM: A user deletes a file, even though that user was assigned the No Access permission for the file.

In UNIX file systems, users who have the Write permission to a folder can delete files in the folder. Because Windows NT supports POSIX programs that are designed to run on UNIX file systems, the NTFS Full Control permission allows users to delete files in a folder even if the user has the No Access permission for the file.

(For those not versed in NT, "No Access" is a "special" permission that overrides everything if access conflicts arise. If a user attempts to access a folder, but any one of the groups he is a member of has No Access to the folder, it's Permission Denied no matter what his other permissions are) Now, first of all, I'm unfamiliar with POSIX, but as far as my memory serves, I can't think of ANY mode resembling No Access in any OS other than NT. Second, A friend of mine (who is somewhat more versed in Unix environments than I am) says that it sounds like NT's Full Control permission is similar to root, and, of course, why the hell would root be denied access to ANYTHING?"

Now this sounded fishy to me so I tried this on my Linux box, removing a directory called ".temp.dir" which had some random contents I had floating in my home directory. The results were as expected:

rm: .temp.dir: Permission denied
rm: .temp.dir: Directory not empty

I'm using fileutils v3.16, but I'm sure this behavior dates back earlier than this version.

So can someone clarify this. Does POSIX actually have this behavior, or is this actually a bug in NT?

Comments

POSIX Compliance

[Anonymous Coward]

Under Linux (which is POSIX-compliant), any user with write access to a directory can delete files in that directory (even if they do not have write access to that file). An exception to this is made if the "sticky bit" (+t) is set on a world-writable directoy. In this case, only the owner of the directory or file can delete a file.

It is possible for root to receive an "access denied" message on a UNIX system. If a file is marked as "immutable" in Linux, root can not make any changes to the file (without first removing the immutable flag). Programs are not supposed to assume they will have access to a file.

POSIX does not have a "no access" permission, so the behaviour would be undefined when that permission is set. This makes it hard to say whether NT's behaviour is a bug. Microsoft could have given an "access denied" message (programs should always be prepared for this), but this would be incorrect if they were trying to acheive strict POSIX compliance (not all programs are prepared for this). If you give someone "full access" to a directory, delete permission is implied anyway - if you don't want someone to delete files, don't give them full access.

Depends on the meaning of "permission"

[SEWilco]

How can it be a fault if one OS does not support something which has no equivalent in another OS?

Once upon a time, DOS had no subdirectories, only top-level directories. So what should or could happen if a program on DOS tried to reference a directory which was not at the top level? Is it a failure in DOS or in the program? (Eventually, MS announced that they copied a feature of UNIX which allowed directories within directories...)

Now, if an OS has a "must-write" mode, which requires that a file must be written to if it is opened, whose fault is it if another OS does not support that capability? You can't blame an orange for not tasting like an apple.