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?

huh?

[josepha48]

Question: Isn't deletion a form of modification? If I were to open the file and delete its contents wouldn't that be modification?(Yes) So deleting a file that I do not have modification privilages to can be considered a bug. IMHO. It just does

huh?

[josepha48]

Question: Isn't deletion a form of modification? If I were to open the file and delete its contents wouldn't that be modification?(Yes) So deleting a file that I do not have modification privilages to can be considered a bug. IMHO. It just does does not sound right.

Re:You've overlooked something

[coyote-san]

Ah, but did MS *intend* for hard links to exist in NTFS? Your phrasing leaves that open to question. I've seen hard links under MS-DOS, and it was not pretty.

The details involve MS-DOS hacking (yes, it was done). Some people wrote directory access routines that worked with BIOS calls, and they discovered that they could implement *very* effective write-protected files by writing the file names in lower case letters. Someone else made hard links by having multiple directory entries point to the same FAT entry for the file. This works find until someone deletes any of those files (or directories) and the FAT entry is marked "available for reuse."

Re:POSIX Compliance

[aetius2]

You guys are misunderstanding how NTFS does its permissions. NO ACCESS is a special permission, to be used in specific instances where there should be a very limited number of people who can access something. It is a failsafe, generally used on the Everyone group, to make sure that no one gets access through a slip-up in assigning a group or permission. However, it cannot defeat the FULL CONTROL permission. Why? Because FULL CONTROL does NOT allow you access to the file -- it gives you control over the external aspects of the file, including security and ownership. The relationship between FULL CONTROL and NO ACCESS is also a failsafe -- If NO ACCESS could block everything, then a user could create innumerable large files that the administrator could not then delete, creating a denial of service by filling up the hard drive permanently(unless you're running some sort of quota software). All that being said, this IS a bug. However, it is one that has no real impact at all. I can delete the offending files if I have FULL CONTROL, or I can change the security on the files with my FULL CONTROL and then delete them (or read them!). The end result is the same -- and it keeps a serious problem from ever occurring.

Nothing to do with a non-empty dir

[A nonymous Coward]

Your basic premise is correct, and Micro$hit is just going nyahh nyahh here. But the problem has nothing to do with non-empty directories; I would hope that's illegal even on NT, unless NT also recursively deletes the contents.

A better UNIX example would be a dir to which you have write permission, with a file in it owned by somebody else. Whether or not "you" in this instance is root (which apparently corresponds to NTFS Full Control permission), UNIX will let the directory owner delete the file, on the basis that it's the owner's directory. The only difference between being root and being a regular user is that root can pretty much go to any directory regardless of owner.

Why NTFS would allow somebody to create indestructible inaccessible files in somebody else's directory is beyond me. I have read other articles on problems with NTFS and it doesn't sound like a particularly logical file system to me, more like they purposely wanted to be different just for the sake of being different and making porting difficult.

BTW, POSIX generally means Unix. Or that subset common to all Unices, the intersection of them, something liek that :-)

--

You've overlooked something

[coyote-san]

You've overlooked something important. In Unix, directories are nothing more than pointers to independently managed files and there is *not* a 1:1 correspondence.

Consider the following sequence:

$ mkdir /tmp/foo
$ touch /tmp/foo/A
$ mkdir /tmp/bar
$ ln /tmp/foo/A /tmp/bar/A
$ rm -f /tmp/foo

Is the file "A" deleted? Nope, you can still access it via the hard link established in /tmp/bar. (Symlinks would be lost, of course.) To a Unix filesystem that file is an equal child of *both* (or all) subdirectories.

I don't know about the internals of NTFS, but earlier MS filesystems did not have the concept of a hard link. Well, not intentionally. Hard links change your semantics in some pretty odd ways, at least when you first encounter them. For instance, in this case the person might be able to delete the file entirely, but he can't change its contents.

Today, hard links are still used. IIRC, gzip uses a couple hard links to a single executable that behaves differently according to the value of argv[0]. If it's 'gzip', it compresses a file or stdin. If it's 'gunzip', it decompresses a file. If it's 'gzcat', it decompresses stdin.

Not a bug!

[Gralbe]

Before I was at all versed in the Ext2 filesystem I noticed this issue because of Perl. All anyone really needs to do it put the 'problem' in the proper perspective.

The short of it is that, yes, you should be able to delete a file that you cannot modify. Since I'm no Guru, check out this link from the Perl docs [perl.com].

Hope that helps!

Gregg

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.