From ReactOS

According to KJK::Hyperion, filesystems that don't implement ACLs themselves can't have access control per-user in windows. So if you use fat32, then there is not and never will be any security checks on the filesystem.

This needn't be the case though. Nothing stops you from adopting a layered model in which a security database is maintained, and ACL functionality is emulated by the top filesystem while the lower filesystem actually provides files. This separation of responsibility makes good sense and would provide benefit because the windows ACL *is* effective when it comes to plumbing devices, filesystems and such.

So basically, this is my thought:

Provide a "FSSec.sys" driver that presents as simple an interface as possible while still filtering requests about files based on some security information. On every file system, fssec would keep an ACL database in the root, and maintain this database based on file ACL changes. Further, fssec would prevent access to files in ways that are not allowed by the ACL. The underlying filesystem, whatever it was, would have as much information as possible communicated to it by the upper filesystem as possible, but any type not supported would be ignored.

The FSSec driver would be expected to disallow access to the physical device once the driver stack was built, as well as to it's own acl database. Hopefully, windows' security model is at least good enough to prevent such access to device objects that are in memory.

By filtering requests to a lower-level filesystem, users could combine any appropriate security model with any filesystem they like, including fat32 (which is desirable because it's use is widespread). In addition, extra security models could be developed without needing changes to the filesystem driver or structure of the filesystem (which are both complicated and sensitive).

--

I supposed this would work for any filesystem except ones that have built-in ACL support ( i.e. NTFS )?

Royce3