Adaptec 5325301656 Administration Guide - Page 95
File and Directory Permissions, Share Level Permissions, Where to Place Shares
UPC - 753253016563
View all Adaptec 5325301656 manuals
Add to My Manuals
Save this manual to your list of manuals |
Page 95 highlights
Configuring Share and Folder Security Overview File and Directory Permissions GuardianOS supports two "personalities" of file system security on files and directories: • UNIX: Traditional UNIX permissions (rwx) for owner, group owner, and other. • Windows ACLs: Windows NTFS-style file system permissions. Introduced in GuardianOS 5.0, Windows ACLs fully support the semantics of NTFS ACLs, including configuration, enforcement, and inheritance models (not including the behaviour of some built-in Windows users and groups). The security personality of a file or directory is dependent on the security model of the SnapTree or Volume in which the file or directory exists (see "SnapTrees and Security Models" on page 84). Note Files and directories created pre-GuardianOS 5.0 will continue to have the same permissions they had before, and will continue to be enforced as they were. This includes both UNIX permissions and POSIX ACLs. When a Windows user changes permissions on a file or directory created pre-GuardianOS 5.0 with a POSIX ACL, the file will be updated to the new Windows security personality. Share Level Permissions Share-level permissions on GuardianOS are applied cumulatively. For example, if the user "j_doe" has Read-Only share access and belongs to the group "sales", which has Read/Write share access, the result is that the user "j_doe" will have Read/Write share access. Note Share-level permissions only apply to non-NFS protocols. NFS access is configured independently by navigating to the Security > Shares page, selecting a share, and clicking the NFS Access button. Where to Place Shares For security and backup purposes, it is recommended that administrators restrict access to shares at the root of a volume to administrators only. All Snap Servers are shipped with a default share named SHARE1 that points to the root of the default volume vol0. The share to the root of the volume should only be used by administrators as a "door" into the rest of the directory structure so that, in the event that permissions on a child directory are inadvertently altered to disallow administrative access, access from the root share is not affected. This also allows one root share to be targeted when performing backups of the server. If it is necessary to have the root of the volume accessible, using the Hidden option helps ensure only those that need access to that share can access it. Chapter 6 Share and File Access 81