SetACLCommand

The SetACL command sets restrictive Access Control Lists (ACLs) onto an IdP installation directory tree using repeated calls to the Windows icacls command.

Starting with V5, a new Windows installation has no restrictive permissions set. You must not put such a distribution into production and the SetACL command allows you to constrain permissions.

Unless using the now-deprecated Shibboleth Jetty installation package, which uses this command to restrict access appropriately, you will need to explicitly restrict access to whatever degree you prefer. In such cases, this command will not do exactly what you need, but it does provide a skeletal example you can copy to your own scripts to apply to your servers.

Usage

C:\opt\shibboleth-idp> bin\setacl.bat [User] [Owner]

The two parameters are both optional and are:

• User

  • An account to be given explicit read access to the distribution, and write access to the log folder. This is to allow the web server to be run by a limited-permissions account (so the webserver cannot write to other locations). The default is that no user will be specified and the webserver will be run as the default Windows Service account (which is usually highly privileged).

• Owner

  • An Identifier which to be made owner for the entire tree. Defaults to Administrators

Details

The batch file is copiously commented; the work is done in 3 stages

1. Ownership of the entire tree is passed to the identifier specified in the second parameters (or Administrators). This is needed because if the tree is owned by a user who is going to be denied permission things 'degenerate'.

2. Restrictive ACLs are added to the tree to disallow non-elevated access.

   1. In a first pass the directories are restricted. The idp.home location and all the subdirectories are set to allow SYSTEM and Administrators full access (and the provided user read and traverse access). All existing ACLs are stripped and any inheritance is removed at the root. Inheritance is enabled on these directories, so that files subsequently created in these folders will assume these permissions.

   2. In a second pass all the files below the installation root are given the same access as the directories (as noted above)

3. If a User parameter is specified, then it is also given FULL access to the directories and files below the logs directory. This allows a standard IdP installation to write to the usual place.

Other Notes

While the logs directory is a pretty routine assumption, there are often other directories that the web server process' account needs to create and write to, namely cache directories for backing up metadata. These locations are set by you in the configuration depending on your choices, and so you will have to consider adjusting rights based on that.