Adaptec 5325301656 Administration Guide - Page 95

File and Directory Permissions, Share Level Permissions, Where to Place Shares

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

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204
  • 205
  • 206
  • 207
  • 208
  • 209
  • 210
  • 211
  • 212
  • 213
  • 214
  • 215
  • 216
  • 217
  • 218
  • 219
  • 220
  • 221
  • 222
  • 223
  • 224

Configuring Share and Folder Security Overview
Chapter 6
Share and File Access
81
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.