New
#21
When you cannot copy a specific set of files...
...start a thread and we will try to figure out why
Need help understanding Windows NTFS permissions
-
-
New #22
-
New #23
Importance of NTFS Permissions and How to Read Access Control Lists
"Windows Security" is a broad title; this thread is well defined, we're clearly on the topic of NTFS permissions.
I'm going to begin by saying that the topic of NTFS permissions is involved for a large many, and when I say 'many' I am referring to the population of technical folk too, power users and gurus alike... and if I had to say it, I reckon a great majority of the experts on this forum do not understand the concept of permissions themselves well enough to be giving advice how permissions should be arranged.
NTFS permissions is the glue that holds Windows together: Windows, as it stands right now, could not operate on any other filesystem because of how bound to NTFS permissions it’s become. Windows relies on NTFS permissions, and NTFS is here to stay for a long time, so I highly recommend that you, reading this, get moderately acquainted to the most confusing part of NTFS. Understanding how permissions work in Windows will significantly help in understanding how Windows works in general. NTFS permissions does not have to be such a difficult concept. If we all just took the time to read about how they work, and practised using them frequently enough, there wouldn't be so many misconceptions and false ideas given by many tutorials and individuals pertaining to how permissions really work.
Permissions tend to stump me too at times because there's so much of it everywhere it can be a real headache to manage. Many objects in Windows have permissions on them, and there are a number of types of objects in Windows that have their own sets of access rules. These different objects are called Securable Objects and can have permissions. A list of securable objects include the Filesystem (the common variety that really gets to us when we're faced with that all too familiar "Access is Denied” message when doing something to a file), Registry keys, Processes, Services, Shares, and the list continues. Almost everything in Windows carries permissions.
I cannot explain all there is to know about permissions in Windows here, it'll take pages and pages. If you are interested in knowing how NTFS permissions work, I recommend giving this documentation a thorough read through, and then practise modifying permissions yourself.
If you're really up for it and have a strong understanding of how Windows works, I recommend the TechNet documentation concerning NTFS permissions which can be found here.
I'm not just going to leave a stack of reading for everyone to do, and you empty handed, Kefren. Just so you can get the gist of how Windows permissions work, I'm going to explain how one can read the Access Control List (ACL) of a filesystem object (such as a file, directory or drive) in an extremely cut-down, brief way, with examples to follow.
Firstly, I’d like to skim across a few terms. I’ll define each of them in the most layman way possible:
- Access Control List (ACL): basically the list you see when you view the security tab on a file,
- A Principal: a single user, a group, a service, or other object with an SID,
- Access rule / Permission: basically the things that govern what you can do with the object (e.g. Write, Read, Full Access),
- Access Control Entry (ACE): Allow or Deny (Type) + Principal + Access rule(s)
The first thing to keep in mind when viewing an ACL (the list you see when viewing a file's security tab), is the order of permission precedence. Permission precedence says that all Deny permissions take precedence over Allow permissions, except for Explicit Allow permissions which take precedence over Inherited Deny permissions (in my experience, these cases are actually quite rare to come across. You can safely get by by just assuming that all Deny permissions will precede Allow permissions). The following list summarises permission precedence,
- Explicit Deny
- Explicit Allow
- Inherited Deny
- Inherited Allow
The other important thing is knowing what Access Control Entry (ACE) is relevant to you (your logged in user). You’re either a specific user or you’re not; your either part of a group or your not. It’ll make sense with a few examples...
Another point, if your user isn't mentioned on the ACL at all, you are denied (full access). This means that if an ACL has no ACEs, then no one has access to that object, only the owner of that object would be able to make permission changes.
NoteOwnership is a separate but related concept to Permissions. The owner of an object does not (directly) give that owner more rights to that object. The owner of an object simply allows them to make permission changes to that object regardless of what the ACL of that object contains.
And the finial point of importance that you must know to understand how permissions are decided is the cascading nature of the access rules. Again, this'll make sense after an example.
To keep things simple, I'm going ignore the concept of inheritance in these examples. Also, I'm going to limit the access rules used to Read, Write and Execute.
The Scenario
Alice, Jake, Sally, and Ben share a machine. Along with the Everyone group, the groups that these users are a members of are summarised below,
- Alice: Users, Administrators;
- Jake: Users, Administrators;
- Sally: Users;
- Ben: Users, Guests
Eg 1: There is one ACE on a certain file, “OrangeCheese.txt”, that ACE being Users (group) which has the access rules of Read, Write and Execute. What permissions does Alice have and why?
This is what the ACL would look like for “OrangeCheese.txt”,
A: Alice would have Read, Write, and Execute access because Alice is apart of the Users group.Code:+--------+-------+-----------+----------------------+ | Object | Type | Principal | Access | +--------+-------+-----------+----------------------+ | Group | Allow | Users | Read, Write, Execute | +--------+-------+-----------+----------------------+
Eg 2: A file has three ACEs in it’s ACL. These ACEs are Users, which has the access rule of Read, Administrators, which has the access rule of Write, and Everyone, which has the access rule of Execute. What permissions does Alice have, and what permissions does Ben have?
A visual of the ACL,
A: Alice has all three access rights, Read given from the Users ACE, Write given from the Administrators ACE, and Execute given from the Everyone ACE. Ben, on the other hand, has Read given form Users, and Execute given from Everyone.Code:+--------+-------+----------------+---------+ | Object | Type | Principal | Access | +--------+-------+----------------+---------+ | Group | Allow | Users | Read | | Group | Allow | Administrators | Write | | Group | Allow | Everyone | Execute | +--------+-------+----------------+---------+
Eg 3: There are two ACEs in the ACL of the file “Carrot-Cake-Recipe.docx”. Those ACEs are Alice, whose access rules are Read and Execute, and Sally, whose access rules are Write and Execute. What permissions does Alice have, and what permissions does Ben have and why?
The ACL of “Carrot-Cake-Recipe.docx” in visual format,
A: Alice has the permissions of Read, Execute (granted by the Alice ACE) as well as Write access (granted by the Users ACE), while Ben would be denied full access as he is not "mentioned" in the ACL.Code:+--------+-------+-----------+----------------+ | Object | Type | Principal | Access | +--------+-------+-----------+----------------+ | User | Allow | Alice | Read, Execute | | User | Allow | Sally | Write, Execute | +--------+-------+-----------+----------------+
Eg 4: A file has 4 ACEs in it’s ACL: Sally with Read and Execute access; Alice with Read and Write access; Users Denied Execute access; and Jake with Execute access. What permissions do these users have?
The file’s ACL,
A: Sally has only Read access because the Users ACE denies her from Execute. Deny permissions take precedence over Allows. Alice has Read and Write access. And lastly, Jake has no access whatsoever. Although the Jake ACE is allowing the user, Jake, Execute access, the Users ACE denies Jake Execute as it is a Deny permission and will take precedence.Code:+--------+-------+-----------+---------------+ | Object | Type | Principal | Access | +--------+-------+-----------+---------------+ | User | Allow | Sally | Read, Execute | | User | Allow | Alice | Read, Write | | Group | Deny | Users | Execute | | User | Allow | Jake | Execute | +--------+-------+-----------+---------------+
Eg 5: There are 6 ACEs in the ACL of a file. The ACEs are,
- Alice, Read and Execute access;
- Jake, Write access;
- Sally, Read;
- Administrators, Read, Write and Execute;
- Users, Denied Write;
- Guests, Denied Read and Execute
What permissions do Alice, Jake, Sally, and Ben have? You guys can help me answer this one.Code:+--------+-------+----------------+----------------------+ | Object | Type | Principal | Access | +--------+-------+----------------+----------------------+ | User | Allow | Alice | Read, Execute | | User | Allow | Jake | Write | | User | Allow | Sally | Read | | Group | Allow | Administrators | Read, Write, Execute | | Group | Deny | Users | Write | | Group | Deny | Guests | Read, Execute | +--------+-------+----------------+----------------------+
Last edited by Pyprohly; 21 Aug 2015 at 22:57. Reason: Fixed typos, paragraph spacing, and added a little more colour
-
New #24
Good point, I can see that a bit more now: the main problem at the start is you don't understand what systems are in play, and don't have the vocabulary to clearly explain what you don't understand ("since you don't know what you don't know)". It's like when I first had problems, I didn't even know about the permissions or security tab, I was scratching my head wondering why I couldn't do things with some of my files anymore... It makes a bit more sense now.
Thank you for your patient and clear explanation - I can see why this could be useful in multi-user environments. I can follow it though have to go back and forth trying to parse the logic behind the examples, since I was never much good at anything that reminded me of algebra!
groups/users + allow/deny + write/read combos etc =...
I'll come back to this and study it again.
One thing - it still makes me wonder why I can't "reset" and "simplify" every file and folder on my PC so that they all allow me (user? Karl? administrator) to do what I want with full permissions, and have no other categories (except maybe System, if Windows needs to do things). So many types of user categories when I am the only human on my PC seems like overkill for the "one PC/one human" setup that is very common in homes. I guess it's historical and comes from Windows NT which was aimed at corporate/complex systems, and replaced the older system for home users (e.g. Windows 98?), but it did seem to bring in a complexity that is more than is needed single-user setups.
Or maybe reinstalling Windows on C: does that "reset" thing (though resets it to a complex system, not the one I posit above, of just "me" and "my machine" as groups/users)? But would that also reset the personal data files/folders on my partitioned D:, or would they stay affected by previous installations and locations?
Anyway, many thanks again for your patience.
-
New #25
Great post Pyprohly.
I learned everything I need to know. Stay the hell out of NTSF security is my plan. I don't have the time desire or brain power for all of that.
-
New #26
Is Ben a guest or an admin
Your post was excellent; however, I'm going to provide more info on ACEs because your technet and helgeklein links do not include some ACE features that started with Vista. These new features have no GUI and might very well cause extra security warning messages when dealing with files from external drives (which the OP mentions).
https://msdn.microsoft.com/en-us/library/bb625957.aspx
Before Vista, ACEs directly impacted ACLs. After Vista, some ACE settings can be changed without impacting ACLs.
-
New #27
Because it's not clear what a 'reset' means when it comes to permissions.
A common technique used to 'reset' the permissions of an individual file/folder is to disable then re-enable inheritance on that object. This removes any explicit permissions on the object. Of course this won't exactly work if a parent object (a folder higher up) is the thing giving off the bad permission(s). Re-enabling inheritance is what the Icacls Command Prompt command does when using the command on a file with the '/reset' switch.
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.
Well yes, because you're going to move all your files off the volume and back on again. Permission information is not attached to a file or folder, and upon moving the item from the filesystem, permission information will be lost.
I forgot to answer your 10 questions, Kefren. They're good questions to be asking btw and don't feel 'dense' asking any of them.
1. You cannot disable NTFS permissions. Windows absolutely depends on it.
2. I don't exactly know how your permission problems came about, Kefren. Why you cannot access your files may be because they're lacking appropriate Access Control Entries because a parent object has inheritance disabled. Or perhaps inheritance on the new files haven't kicked in at all and they still have the ACEs from you old OS caused by the software that you used to move your files which copied over permission information too, it's not supposed to, and didn't enable inheritance on the files or some folder above those files.
Permission issues are never to do with ownership; the owner of a file has little to do with the file's permissions.
These question shouldn't matter anyway because all permissions information should have been discarded after the move.
3. NTFS permissions and the Windows security model and all it's components cannot be disabled. Things just wouldn't make sense without them. For instance, what would an elevated process (a process with the Administrators group having Full Control) mean? Thus what would be the purpose of UAC? Windows is not designed to exist without these features.
4. NTFS permissions are stored in the filesystem (the NTFS filesystem. Hence the name "NTFS permissions" and not "Windows permissions") itself, that is, sort of next to all the files themselves (but not physically next to).
The registry's purpose is to serve as a place to store program settings. It does not keep a list of all the files on the volume and their details.
5. Permission settings are not stored on the files themselves for reasons like you mention, Kefren: files could be bloated with unwanted data.
6. 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.
7. Permissions are a property of the filesystem. 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.
8. All versions of Windows have NTFS permissions, at least ever since NTFS became the standard. The Windows security model may have changed over time but it's practially the same across all Windows versions today, so getting a more 'basic' version of Windows won't make a difference.
9. All modern OSs have their own form of permissions. Windows' is just quite robust and thus confusing for many.
Again, NTFS permissions are a property of the filesystem. Move a file onto a different OS and the old permissions will be scrapped. The new OS's permissions will be used.
10. Hopefully my previous post answers this one.
Haha. Not the reaction I was hoping for. Permissions should not be feared, they should be understood and not avoided but actually used.
Ben is a guest, apparently...
as he is apart of the Guests group.
-
New #28
From post #27 by Pyprohly
I don't fear permission.Haha. Not the reaction I was hoping for. Permissions should not be feared, they should be understood and not avoided but actually used.
But I do know when I don't know.
Until I learn the needed information and application of such information, I leave it alone on the most part. I have admin permission and I do when needed take ownership of some things but I do not dig deep into NTSF permission.
**Three reasons.
1. I don't have the needed knowledge.
2. At my age I don't have the time or desire to gather all the needed schooling. Their are volumes wrote on such things.
I tip my hat to those that have knowledge to do such things.
3. My systems work just fine and digging into the registry and changing permission of NTSF is not needed by me.
The best reason is if needed I can ask you for help because I know when I don't know.
But I do know who does know. You.
-
New #29
Many thanks Pyprohly! Things are a lot clearer now. I'm further reassured by things like
"Permission settings are not stored on the files themselves for reasons like you mention, Kefren: files could be bloated with unwanted data. [...] If you move a file from an NTFS filesystem to a FAT32 filesystem, the NTFS permissions will be completely scrapped."
Good, that's how I wanted it to be. It's simply because a right click>properties was falsely taken by me to display information within the file itself (like a printed label stuck to a manila paper folder).
I'm also picking up other information along the way. Maybe useless stuff, or things everyone else knows, but it is clicking together logically. For example, you said
"3. NTFS permissions and the Windows security model and all it's components cannot be disabled. Things just wouldn't make sense without them. [...] Windows is not designed to exist without these features."
and
"7. If your drives are FAT32 formatted, files on them won't have permission information whatsoever as FAT32 has no support for permissions."
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. It's a useful reminder. I recently couldn't find a web page listing what system the hard drives can be formatted in for different versions of Windows. It doesn't seem to be covered in the Wikipedia pages about File Systems>Windows (https://en.wikipedia.org/wiki/File_s...rosoft_Windows) or NTFS (https://en.wikipedia.org/wiki/NTFS) or Microsoft Windows (https://en.wikipedia.org/wiki/Micros...ws#Windows_3.x). I'd expected a table for each version of Windows, showing what file systems you could use for each (or the only one that worked in each case). Your answers at least let me work it out for recent versions.
Clarifications on things I'd said
Kefren: "One thing - it still makes me wonder why I can't "reset" and "simplify" every file and folder on my PC"
Pyprohly: "Because it's not clear what a 'reset' means when it comes to permissions."
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".
"Of course this won't exactly work if a parent object (a folder higher up) is the thing giving off the bad permission(s)."
I think that's my residual worry, that because files and folders all have different setups, maybe some of them are "wonky". 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.
"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."
As with above - 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 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. Who knows, maybe over I time I copied that folder and renamed it (perhaps because it has lots of complicated subfolders that I can't be bothered to rebuild, such as my annual tax return folders which I copy and rename as 2012-13, 2013-4 etc - all copied from an original folder).
Now that I understand enough to write this paragraph, maybe that could even be a cause of these weird problems that occur sometimes and are hard to identify? Maybe at some point a file or a folder it was in got wrong permissions like that. It looks fine on the surface but then causes problems e.g. when synchronisation software copies it. And if the back-up drive is NTFS (to enable files over 4GB) then it will always be keeping those "wonky", over-restricted permissions. It could be years before they cause problems, so tracking it back to a single hand-slip years earlier wouldn't be possible - it would be a mystery. Partly because the things like permissions changed with no warning to the PC operator. Well, just supposition, but it's where my thinking came from for having a way to "reset" or "correct" permissions on everything on a whole drive. Second best would be something that scans every file and folder, and flags anything different from the files around it.
I should add that I am not particularly bothered about C: - that can be set up however Windows wants. I am only thinking of my D:, all my personal data and documents and photos etc. There's no reason why anything on that drive should have different permissions from everything else. It's that D: that I would want to nuke or reset or just check for discrepancies. (There, all of this discussion, and I am only now able to really clarify a core element of what I mean!)
So ignore my earlier comment about nuking the whole PC from orbit - I am only bothered about my D:, and my own files and folders. That's the gist of it!
Additional
Kefren: "maybe reinstalling Windows on C: does that "reset" things?"
Pyprohly: "Well yes, because you're going to move all your files off the volume and back on again. Permission information is not attached to a file or folder, and upon moving the item from the filesystem, permission information will be lost."
I think I understand, though my reinstall system is:
C: Windows and programs
D: personal data
I wipe C:, reinstall Windows. But D: has not been touched - the data has stayed there on an NTFS drive. I've not moved "all the files off and back again" in that case.
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?
Implications:
- If it is all stored on the C: then reinstalling Windows (with a C: reformat) will also reset all permissions info on D:.
- If it is all stored on the D: then reinstalling Windows (with a C: reformat) will do nothing at all to the permissions on C: and D:
- If it is stored on both the C: and the D:, relating only to files on that drive, then reinstalling Windows (with a C: reformat) will also reset all permissions info on C:, but do nothing at all to the permissions on D:.
(All of which have different implications for if a folder/file has gone "wonky" on the D:; further implications for backups on portable backup NTFS drives).
-
New #30
Kefren:
If I understand earlier posts in this thread, the "somewhere else" is the Master File Table. And I think each volume has its own MFT. C would have one. D would have a separate one.
https://en.wikipedia.org/wiki/NTFS#Master_File_Table
Scroll down about half way in the above link.
If I understand this thread, permissions for all data files on D could be totally scrubbed by moving those files to a drive E.
But--wouldn't they then necessarily acquire the permissions of drive E, which may or may not be an improvement?
Maybe move them to a newly formatted NTFS drive E? Would this necessarily give the moved files a completely benign "default" set of permissions? If these files were then moved back to D, would they not reacquire the undesired permissions?
Maybe you'd have to reformat D before moving the files back from E to avoid reacquiring unwanted permissions?
If you want to scrub permissions from all files on D by moving them to another partition E, is there any reason E should be NTFS rather than FAT32, other than the file size limitation of FAT32, given the assumption that the files would be immediately restored to D after the scrubbing?
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.
I could certainly tolerate such a storm on C--I'd just reinstall Windows. But it could be devastating for data files kept on D if they were rendered inaccessible. Hmmmmm......I guess my backups of D have another set of permissions?
Quote
Related Discussions