Where does Windows store ACLs and do ACLs follow a file from one machine to another?

Question

Our app uses a component that requires a license file in the directory with our executable, which happens to be a .NET WinForms app though I think it is immaterial to this question. When installed on some XP Pro machines (just three out of several hundred thus far), the component throws a license exception. So I regenerated the license file and sent it to the component vendor (EMC Captiva), where the vendor claims the error is due to the fact that the "Users" group has no read permissions on the file. The user who encounters the error happens to be a local admin, but that is besides the point as I am still curious about the more general question.

So my question is, are ACLs stored in a file such that they follow the file throughout its life, especially when the license file was generated on my dev machine (machine 1), stored in Subversion (machine 2), checked out of source control by TeamCity (machine 3), packaged into an installer by InstallShield (machine 4), and finally deployed to the customer's machine (machine 5) where it was installed by an Administrator? What about after I generate the file on my dev machine (machine 1), upload it to the component vendor via their support site (machine 2), and the support person downloads it to their machine for inspection (machine 3)?

I do not know this for sure (which is why I am asking it here), but I assumed each Windows machine stores ACLs in some central directory/list/table managed by NTFS rather than stored within the file. What happens to the original file's ACL when it is copied from one machine to another, stored in Subversion, packaged into an MSI, etc? Can someone point me to some good references where I can read up on this?

Julienne

What are you trying to do? What would packing ACLs into an MSI package be good for? You cannot control what people do to a file once it left your own computer, if that's what you have in mind. – Extraterritoriality

As I said: The ACL is not part of the file. TortoiseSvn cannot even see the ACL. – Extraterritoriality

That is what the component vendor seems to be suggesting, but I do not buy it. – Julienne

The cause of the error you see can only be nailed down if you inspect the actual file permissions on the client machine. Either they are wrong (unlikely, though possible), or the file is simply in the wrong place (or the app looks in the wrong place for it, which is the same thing essentially). – Extraterritoriality

Answer 1

ACLs are stored in the part of an NTFS partition that does all the background plumbing - the MFT (Master File Table).

The ACL does not follow a file around, since it is not a part of the file (just like the filename it is metadata). The file can cross partition type boundaries (NTFS->FAT), the ACL cannot.

Now if you move a file within one NTFS partition, you might get the impression that ACLs actually follow the file around. This is because during a move, only the filename in the MFT is actually changed. Everything else stays the same.

If you copy a file or move it to another partition or computer (which is actually a copy+delete operation), the copied file will by default inherit the permissions of it's new container (the inheritable ones only, to be precise).

However, there are tools that are capable of retaining the ACL of a file after a copy operation (simply by recreating it on the target file after the copy operation) even over partition or computer boundaries. xcopy can do that, among others.

But since an ACL can contain SIDs that are "domain owned", an ACL entry might not actually be meaningful to the target computer that is not part of the same domain (for example when taking home an NTFS-formatted USB drive). In that case the ACL entry will have no effect.

Other SIDs are "well known", like the "SYSTEM" SID. These will actually be recognized across domain borders.

Extraterritoriality

So you agree the component vendor providing me support is probably not seeing the same ACL the user sees on her target machine, right? Also, can you suggest some online resources where I can read more on what you said? – Julienne

Once the file is on the machine of the client/user, it's gone. You cannot control it in any way by setting ACLs on it, even if such a thing was at all possible. Your ACLs are probably meaningless on the target machine, and they are in any case volatile. Anyone could simply overwrite them. – Extraterritoriality