# Customizing Disk Security

Custom changes to disk security metadata should not be applied to the `DiskSecurity.xml` file itself. The disk security metadata can be contained in multiple files. All disk security metadata do not have to be contained only in the `DiskSecurity.xml` file. You can create any number of additional disk security metadata files. To customize disk security, you should create an additional file with the `xml` extension in the `%plesk_dir%etc\DiskSecurity` directory and specify additional security rules in the file. This will enable you to track changes and manipulate sets of security metadata easily.

To customize disk security rules in Plesk:

1. Log in as administrator to a Plesk-managed server over Remote Desktop.

2. Determine the Windows objects for which you want to set new security rules.

3. Open the `%plesk_dir%etc\DiskSecurity` folder.

4. In the folder, create a file with the `xml` extension. You can give this file any name.

5. Create disk security rule entries in the file. To do so, use the XML file editor of your choice and the references below.

   Disk security rule entries have the same format as hosting security rule entries. To learn about the entry attributes in more detail, refer to General Security Metadata Structure. We also recommend that you see the example provided below.

6. Once you have finished adding the security rules, save and close the file.

7. Run the `plesk repair` utility with the `--directory-permissions` command and the `-directory <path to the directory>` option to apply the security rules to Windows objects. For example, to apply the disk security rules to the `C:\Temp` directory run the following command:

       plesk repair --directory-permissions -directory C:\Temp

For example, you have an application (say, IIS module) installed into the folder `c:\Program Files\AppName`. This module is used on customers’ sites, but it does not work properly because Plesk’s default security rules prohibit customers from accessing arbitrary folders on the disk. To resolve this, you can create a file named AppName.xml, add your security rules as described further, and place the file into the directory `%plesk_dir%etc\DiskSecurity`.

## Security Rules Example

    <?xml version="1.0" encoding="UTF-8"?>
    <Entries>
    <Entry EntryFlags="0x1" AccessMask="FullAccess" AceFlags="ThisFolderSubfoldersAndFiles" Path="C:\dir1" Account="Psacln" AccounType="1"/>
    <Entry EntryFlags="0" AccessMask="ReadAndExecute" AceFlags="ThisFolderandSubfolders" Path="C:\dir1" Account="Psacln" AccounType="1" SubPath="dir2"/>
    <Entry EntryFlags="0" AccessMask="FullAccess" AceFlags="ThisFolderSubfoldersAndFiles" Path="C:\dir1" Account="Psaadm" AccounType="1"/>
    </Entries>

## Explanation

- AccessMask=”FullAccess” indicates the “Full control” permission and `AccessMask="ReadAndExecute"`—generic execute.

- EntryFlags specifies what to do with the `AccessMask` permission mentioned above. The `"0"` value of `EntryFlags"` allows the permission, while `"0x1"`—denies.

- Path specifies the path to the object the security rule will be applied to (for example, `C:\dir1`).

- `SubPath` specifies the remaining part of the object path if the path is not fully defined by `Path`.

- AceFlags specifies if the object’s child objects (for example, subfolders and files) inherit the security rule.

- `Account` is a Windows user account type. `Psacln` and `Psaadm` are not standard Windows system accounts. To be resolved in the system, they have AccounType=”1”.

Note

To fine-tune custom disk security, you can combine the “Deny” security rules of the higher level with the “Allow” security rules of the lower level and apply this combination to the same object. In the example above, the first security rule prohibits `Psacln` users from getting full control of the `dir1` folder, its subfolders, and files. The second security rule, on the contrary, allows generic execute but only for one subfolder `dir1\dir2`. As a result, the combination of the two security rules allows `Psacln` users to list the `dir1` folder and its subfolders but prohibits full control of files in `dir1`.