Need help understanding Windows NTFS permissions

Kefren said:

if it is just a case of copying files to FAT32 (or another drive) to remove permissions, surely the security becomes almost meaningless? E.g. a file might be "let users read it but not write to it" (or something) - just copying the file to FAT32 would then let the excluded categories write to it?

Well, from post 27 we have these quotes:

"Another technique, one that I used commonly back when I didn't understand NTFS permissions, is to move the files to another volume, then back again. This works because permission information is typically not preserved, it's scraped. When a file is placed fresh on an NTFS volume, the permissions that the file gains is inherited from the folders above. That means permission settings that already exist are being used and moving an file onto the volume should never bring unwanted permissions with it."

"Permission information is not attached to a file or folder, and upon moving the item from the filesystem, permission information will be lost."

"all permissions information should have been discarded after the move."

"Unfortunately there is no easy method or button you can press to 'reset' a file's permissions. Permissions, if need to be changed, are to be managed manually, and only once if at all."

"If your drives are FAT32 formatted, files on them won't have permission information whatsoever as FAT32 has no support for permissions. If you move a file from an NTFS filesystem to a FAT32 filesystem, the NTFS permissions will be completely scrapped."

Make of those quotes what you will.

I have no idea whatsoever how accurate they are.

Does the bolded quote contradict the others?

@Layback Bear - post #28

I just feel that no one deserves to be confronted with a big red "Access is Denied" when handling their own data. It's unfortunate to see so many asking the person next how to access their files when they can't cannot. NTFS permissions shouldn't be confusing, and it really isn't. The learning curve may be steep but it isn't long.

Kefren said:

I'm also picking up other information along the way. Maybe useless stuff, or things everyone else knows, but it is clicking together logically. [...] Which, when you combine both points, makes it clear that Windows 7 et al can only be installed on an NTFS-formatted drive, not a FAT32 one.

Yes, good inference. Since Windows Vista, NTFS became the standard, and support for installing on FAT32 was dropped.

Kefren said:

I think what I meant is that I would change the permissions on every file and folder on my hard drive to be the same: probably just one user type (either "me" NA, or User, or Everyone, or Administrator) and System. So it's simple with me being able to access all files, and it would stand out if anything was different from that "norm".

"Stand out" if different from the "norm"? Do you enjoy neat and ordered things? Not suggesting a case of OCD or anything, but keeping permissions uniform throughout a volume is rather extreme. I mean it's possible to do what you describe, but it would take time and wouldn't be worth the wait.

Fixing permissions (should the issues happen) is best done as they show up. Reading permissions and editing them accordingly is far more satisfying too.

Kefren said:

But out of the thousands/millions(?) of files and folders on my PC, the only feasible way to be sure they were all the same and what I wanted would be to "nuke them from orbit", set them as the same across the whole PC.

"Nuking" should always be reserved for last resort. Besides, nothing is attacking you; you are in full control already, you just need to know to put that control to effect.

Kefren said:

if different folders have different permissions, then all sorts of wonky things could happen. I might copy a folder of files off my back-up drive (maybe a FAT32 USB), my hand slips, it drops into a different folder (e.g. Program Files or Windows or something). I realise what I've done, copy it into the correct folder (e.g. Holiday Photos). But without me being aware of it, the folder (and contained files) with no permissions (because it was an a FAT32 USB, for example) adopts the permissions of the folder it goes into (e.g. C:\Windows, which is presumably very restrictive), and keeps them even when it is moved elsewhere.

No, that is not what happens.

Yet your understanding at this point is understandable, because I haven't talked much about Inheritance and how it works yet. I think now would be a good time to explain the concept of Inheritance.

Firstly, before I get to that, I'd like to make crystal clear the meaning of "no permissions". On a FAT32 volume, all files are fully accessible by everyone ("full control" to every user) as files have 'no permissions' in the sense that the concept of permissions does not exist. On the other hand, on an NTFS volume, a file having 'no permissions' would suggest that that file's ACL is empty: there are no ACEs defined on its ACL. Thus this would effectively deny all users (full) access to it. (Refer to my post #23 on how ACLs work.)


Inheritance
Permissions on an object can be separated into two groups: Explicit permissions, and Inherited permissions.

An ACL can gain a permission through two ways: by Inheriting permissions from the above objects (this permission will then be an called an Inherited permission), or by having someone or some program explicitly add a permission (this permission is then called an Explicit permission).

The main difference between Explicit permissions and Inherited permissions is that Explicit permissions are 'stuck' to the file it's defined on (when under the NTFS filesystem), in the sense that wherever the file goes, the Explicit permissions will. Inherited permissions, on the other hand, are determined by the permissions that are defined on the parent objects, i.e. the folders above, that are set to propagate child objects.

Inherited permissions don't stay with an object. When an object is moved to a new folder, the old folder's permissions are dropped in place of the new parent folder's permissions (at least the ones that are set to propagate).

If I explained that well enough, this means that files never increasingly pick up permissions through time. For instance, let's say I have a file called Bacon.txt and I place this file into C:\Windows. While Bacon.txt resides in the that folder, it is inheriting permissions from that folder, Windows. If I then chose to move Bacon.txt to another location, let's say C:\foo\bar, all permissions that Bacon.txt was inheriting from C:\Windows are dropped and the permissions that are set to propagate from bar and or foo will be used. The 'parent(s?)' of Bacon.txt has effectively changed, and therefore will the permissions it inherits.

If there was an Explicit permission on Bacon.txt when it was in C:\Windows, that permission will continue to exist when that file is placed in C:\foo\bar or elsewhere.

It's worth noting that Inherited permissions are far more common than Explicit permissions, and Explicit permissions are usually more commonly found higher up the directory structure (in order to define the permissions it's child items should inherit of course. It all starts with Explicit permissions).

Kefren said:

I now know that the permission information isn't stored in the file; not the registry; it is stored "somewhere else" (magical hidden pocket universe in Windows somewhere I can't "see"). The question is, is that place/file that stores the permissions information on the C:, or the D:, or both?

For C:, permissions will be stored on C:. For D:, the permissions will be stored on D:.

It's not a magical place. Permissions are always stored in a volume's filesystem (specifically in the Master File Table, as mention by a few here). The filesystem is also the place where file data is stored.

ignatzatsonic said:

I'm just trying to develop a plausible strategy to try if I ever get in a bad permissions storm, which fortunately has not yet happened.

And never will happen. Permissions don't change themselves. If you don't touch permissions they won't change.

ignatzatsonic said:

I guess my backups of D have another set of permissions?

Backups don't backup permissions. Backups backup data.

ignatzatsonic said:

Does the bolded quote contradict the others?

Ignatzatsonic, I don't see the contradictory.

If you don't have a FAT32 formatted volume on your hard drive, or if you don't have a USB on hand, moving files onto a FAT32 volume is not an easy process (nor is it a "button").

ignatzatsonic said:

I have no idea whatsoever how accurate they [Pyprohly's "quotes"] are.

If you feel uncertain about the accuracy of my posts, please, I welcome you to test the facts I announce and report your findings.



Edit: (must have missed this section while copy-pasting my content)

Kefren said:

if it is just a case of copying files to FAT32 (or another drive) to remove permissions, surely the security becomes almost meaningless? E.g. a file might be "let users read it but not write to it" (or something) - just copying the file to FAT32 would then let the excluded categories write to it?

I don't quite understand this. Why would the permissions be meaningless?

If you were able to copy the file off the NTFS volume, obviously that means that you had the appropriate permissions to do so. When the file is on the FAT32 volume, anything and everyone has full access to that file now, as FAT32 doesn't support permissions; the file will no longer be under the influence of permissions.


Btw, I had the title of this thread be changed to reflect the discussion of the topic more specifially.