FAT Security system policy

From ReactOS Wiki
Revision as of 00:46, 10 May 2005 by Oiaohm (talk | contribs)
Jump to: navigation, search

Why not making the FAT-driver head the security policy?

Enabling security in FAT is not a try to match the level of a modern file system, It is just to lift the function to a "just enough" for home level, meaning:

  • A child should not be able to destroy the installation accidently
  • A familly member shouldn't be able to read all e-mails in another persons account without some deeper knowledge about computers or at least some work to do it.
  • A network computer where a folder is shared should only be read by the people with the correct rights.

[oiaohm]* Does not have errors in basic plan leading to strange effects upseting users if it upsets users they will disable it.

The security should have three levels, one system-file-level where the files of the operating system is protected from everyone without 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. And yet 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 systemfiles that really should be protected allways unless security is turned off.
  • This makes the database with the security policy really smal initially and growin as more rules are added.
  • This makes the synchronize 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 exist but no folder/file anymore, it will be ignored.
  • Then the scandisk or defrag software makes the database up to date.
  • The database should in my opinion be a registryfile 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 scedule 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. Effective methord 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. Hey I just create a folder but now I cannot access it or Hey I just create a file and now I cannot access it or why in cannot I create a file/folder named X.

Renaming needs to be handled. Most likely will be linked to above.

This is all do with Sync I hope someone solves them better than umsdos that syncs on every write/create and delete for each file and directory you are dealing with at a very high speed cost.