Permissions in Directories and Categories

You can use categories to solve access problems. You can also use categories and directories along with permissions to hide objects in the data catalog.

To access an object in the data catalog, a user needs permissions not only on the object itself, but on all parent objects in the path to the target object. For example, to read the file Dinosaurs.doc in the data catalog directory /Shares/pets, you must have read permission on the root directory /, on /Shares, on /Shares/pets, and on /Shares/pets/Dinosaurs.doc. This rule applies to categories as well as to Data Federation directories.

In some cases, a user might need access to a file (or data service or other object) that resides in a data catalog directory to which that user should not have access. For example, suppose you have a /Shares/HR directory that contains both private information about employees and a public list of telephone numbers. To make the phone list available to users outside the HR group, you can create a category for it such as /Categories/PublicInfo. Set the permissions so that members of DomainUsers are allowed to read /Categories, /Categories/PublicInfo, and /Categories/PublicInfo/phonelist.xls. This arrangement allows all Data Federation users in the current domain to read the phone list, no matter how restrictive the permissions are on the file’s home directory, /Shares/HR.

You must take special steps to hide objects in directories and categories. If a user has permission to read a directory or a category, she can list the names of files, subdirectories, and other objects in that directory or category—even those objects to which she has been specifically denied read permission. If you need to hide the existence of an object, it is not sufficient to set deny permissions on the object itself. You must also deny read permission to the directory in which the object resides, to any directories into which the object is linked, and to any categories to which the object has been added.