FAT Security system policy
| This page is probably outdated Nobody is working on this and it is unlikely that anyone ever will. Use of a better file system is recommended instead. |
Why not make the FAT-driver heed the security policy?
Enabling security in FAT does not achieve the security level of a modern file system, It only lifts the security capability to "just enough" for home use, meaning:
- A child should not be able to destroy the installation accidentally.
- A family member should not be able to read e-mails or documents in another person's account without some deeper knowledge about computers or at least have to work to do it.
- A network computer where a folder is shared should only be read by the people with the correct rights.
- Does not have errors in basic plan leading to strange effects that upset users because if it upsets users they will disable it. [oiaohm]
The security should have three levels, one system-file-level where the files of the operating system are protected from everyone who lacks administrator rights. One folder-level making one not so resource-demanding option for older computers or people who just want to protect some folders with their special content. All levels should include the system-file-level. Also, one at file-level where a single file could be assigned a security policy.
- The default permission for all levels should be standard FAT for all folders and files in all levels except for system files that really should be protected at all times unless security is turned off.
- This makes the security policy database very small initially, it grows as more rules are added.
- This makes the synchronization problem less alarming:
- If there is no policy for a folder/file everyone has full access to it.
[oiaohm]No policy for a folder/file use users default option so that a guest account can be locked down and no unmarked directory is accessed outside their allowed spaces.
- If the policy exists but no folder/file anymore, it will be ignored.
- Running the Scandisk or defrag software brings the database up to date.
- The database should in my opinion be a registry file like FATpolicy.dat or acl.dat because we already have the registry file parser => less development needed.
- The synchronizing software (Scandisk or defrag) should be possible to schedule to run at nights or as screen-saver along with anti-virus software.
- Security should be applied in the FAT driver and all sub-systems should be forced to go through it.
[oiaohm] Sync problems that I still see are. An effective method of dealing with a person deleting a folder or file with protection from another OS then user creates a folder/file in ReactOS of the same name that old policy does not jump onto the new file/folder. Users should not wonder, "Hey I just created a folder but now I cannot access it," or "Hey I just created a file and now I cannot access it," or "Why am I unable to create a file/folder named X".
Renaming needs to be handled. Most likely will be linked to the above.
This is all do with Sync. I hope someone solves them better than umsdos. It syncs on every write/create and delete for each file and directory you are dealing with at a very high performance cost.
