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
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:
Log in as administrator to a Plesk-managed server over Remote Desktop.
Determine the Windows objects for which you want to set new security rules.
In the folder, create a file with the
xmlextension. You can give this file any name.
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.
Once you have finished adding the security rules, save and close the file.
plesk repairutility with the
--directory-permissionscommand 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:\Tempdirectory run the following command:
plesk repair --directory-permissions -directory C:\Temp
For example, you have an application (say, IIS module) installed into
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
<?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>
AccessMask=”FullAccess” indicates the “Full control” permission and
EntryFlags specifies what to do with the
AccessMaskpermission mentioned above. The
EntryFlags"allows the permission, while
Path specifies the path to the object the security rule will be applied to (for example,
SubPathspecifies the remaining part of the object path if the path is not fully defined by
- AceFlags specifies if the object’s child objects (for example, subfolders and files) inherit the security rule.
Accountis a Windows user account type.
Psaadmare 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
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