Dell PowerVault LTO4-120HH Dell DR Series System Administrator's Guide - Page 22

Unix Permissions Guidelines, Allows: Full Access, Object Inherit, and Container Inherit

Page 22 highlights

For any existing containers that were created prior to Release 1.1, all files are accessible to any user that logs in to the designated DR Series system. The associated ACL in these existing pre-1.1 release containers support only the following permissions: • Everyone: - Allows: Full Access - Applies to: This folder, subfolders, and files • BUILTIN\Administrators: - Allows: Full Access, Object Inherit, and Container Inherit - Applies to: This folder, subfolders, and files However, you can also apply your own ACLs to existing containers if desired. You can do this by navigating to the root of the share for the designated container, and then flow an ACL down the directory tree. Be aware that the time required for this to complete is dependent upon the number of files and folders that reside in the container. If you create local users, they will be added to BUILTIN\Users. Because the administrator account is a member of BUILTIN\Administrators, if you do experience any problems with ACLs on a container (for example, an ACL was applied that locks themselves or domain administrators out), you can connect via a client as MACHINE\Administrator. At this point, you can edit the ACL (the BUILTIN\Administrators account has TakeOwnership privilege). Be aware that large ACLs can consume additional inodes on the container, which can cause problems if there are a large number of files and folders in the container. Small ACLs (with up to 10 ACEs) can reside in the spare space in the inode, while larger ones can consume an additional inode. Inodes functions as data structures on a Linux (or Unix-like operating system) filesystem where all the information about a file except its name and its actual data are stored. NOTE: Dell recommends that administrators apply a set of permissions to existing containers that are similar to the way defaults are set for new containers. However, careful consideration needs to be given about granting access that addresses any specific security needs for individual users. Unix Permissions Guidelines For a user to create, delete, or rename a file or a directory requires Write access to the parent directory that contains these files. Only the owner of a file (or the root user) can change permissions. Permissions are based on the user IDs (UIDs) for the file Owner and group IDs (GIDs) for the primary Group. Files have owner IDs and group owner IDs. To enable Unix access, the DR Series system supports three levels of users: • Owner (of the file) • Group (group in which the owner belongs) • Other (other users with an account on the system) Each of these three user types support the following access permissions: • Read (read access that allows user to read files) • Write (write access that allows user to create or write to a file) • Execute (access that allows user to execute files or traverse directories in the filesystem) NOTE: A root user has all levels of permission access, and a user can be a member of a single group or of multiple groups (up to 32 groups are allowed in Unix). Windows Permissions Guidelines To enable Windows access, the DR Series system supports access control lists (ACLs) that contain zero or more access control entries (ACEs), and an empty ACE list grants all access requests. The Windows New Technology File System 22

  • 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

For any existing containers that were created prior to Release 1.1, all files are accessible to any user that logs in to the
designated DR Series system. The associated ACL in these existing pre–1.1 release containers support only the
following permissions:
Everyone
:
Allows: Full Access
Applies to: This folder, subfolders, and files
BUILTIN\Administrators
:
Allows: Full Access, Object Inherit, and Container Inherit
Applies to: This folder, subfolders, and files
However, you can also apply your own ACLs to existing containers if desired. You can do this by navigating to the root of
the share for the designated container, and then flow an ACL down the directory tree. Be aware that the time required
for this to complete is dependent upon the number of files and folders that reside in the container.
If you create local users, they will be added to BUILTIN\Users. Because the administrator account is a member of
BUILTIN\Administrators, if you do experience any problems with ACLs on a container (for example, an ACL was applied
that locks themselves or domain administrators out), you can connect via a client as MACHINE\Administrator.
At this point, you can edit the ACL (the BUILTIN\Administrators account has TakeOwnership privilege). Be aware that
large ACLs can consume additional inodes on the container, which can cause problems if there are a large number of
files and folders in the container. Small ACLs (with up to 10 ACEs) can reside in the spare space in the inode, while
larger ones can consume an additional inode. Inodes functions as data structures on a Linux (or Unix-like operating
system) filesystem where all the information about a file except its name and its actual data are stored.
NOTE:
Dell recommends that administrators apply a set of permissions to existing containers that are similar to the
way defaults are set for new containers. However, careful consideration needs to be given about granting access
that addresses any specific security needs for individual users.
Unix Permissions Guidelines
For a user to create, delete, or rename a file or a directory requires Write access to the parent directory that contains
these files. Only the owner of a file (or the root user) can change permissions.
Permissions are based on the user IDs (UIDs) for the file Owner and group IDs (GIDs) for the primary Group. Files have
owner IDs and group owner IDs. To enable Unix access, the DR Series system supports three levels of users:
Owner (of the file)
Group (group in which the owner belongs)
Other (other users with an account on the system)
Each of these three user types support the following access permissions:
Read (read access that allows user to read files)
Write (write access that allows user to create or write to a file)
Execute (access that allows user to execute files or traverse directories in the filesystem)
NOTE:
A root user has all levels of permission access, and a user can be a member of a single group or of multiple
groups (up to 32 groups are allowed in Unix).
Windows Permissions Guidelines
To enable Windows access, the DR Series system supports access control lists (ACLs) that contain zero or more access
control entries (ACEs), and an empty ACE list grants all access requests. The Windows New Technology File System
22