NT blaming an NTFS Flaw on POSIX? 11
"Ok, Whilst skimming through the book I came across the following passage:
(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?"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.
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 emptyI'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? (Score:1)
huh? (Score:1)
Re:You've overlooked something (Score:1)
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 (Score:1)
Nothing to do with a non-empty dir (Score:2)
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 (Score:2)
Consider the following sequence:
$ mkdir
$ touch
$ mkdir
$ ln
$ rm -f
Is the file "A" deleted? Nope, you can still access it via the hard link established in
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! (Score:2)
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 (Score:3)
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" (Score:3)
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.