1mailto(samba@samba.org) 2 3article(Viewing and changing UNIX permissions using the NT security dialogs in Samba 2.0.4)(Jeremy Allison, Samba Team)(12th April 1999) 4 5center(bf(Viewing and changing UNIX permissions using the NT security dialogs))nl() 6center(bf(-------------------------------------------------------------------)) 7 8New in the bf(Samba 2.0.4) release is the 9ability for Windows NT clients to use their native security 10settings dialog box to view and modify the underlying UNIX 11permissions. 12 13Note that this ability is careful not to compromise the security 14of the UNIX host Samba is running on, and still obeys all the 15file permission rules that a Samba administrator can set. 16 17In Samba 2.0.4 and above the default value of the parameter 18url(bf("nt acl support"))(smb.conf.5.html#ntaclsupport) has been 19changed from "false" to "true", so manipulation of permissions is 20turned on by default. 21 22bf(How to view file security on a Samba share)nl() 23bf(------------------------------------------) 24 25From an NT 4.0 client, single-click with the right mouse button on 26any file or directory in a Samba mounted drive letter or UNC path. 27When the menu pops-up, click on the tt(Properties) entry at the 28bottom of the menu. This brings up the normal file properties dialog 29box, but with Samba 2.0.4 this will have a new tab along the top 30marked tt(Security). Click on this tab and you will see three buttons, 31em(Permissions), em(Auditing), and em(Ownership). The em(Auditing) 32button will cause either an error message tt("A requested privilege is 33not held by the client") to appear if the user is not the NT Administrator, 34or a dialog which is intended to allow an Administrator to add 35auditing requirements to a file if the user is logged on as the 36NT Administrator. This dialog is non-functional with a Samba 37share at this time, as the only useful button, the tt(Add) button 38will not currently allow a list of users to be seen. 39 40bf(Viewing file ownership)nl() 41bf(----------------------) 42 43Clicking on the tt("Ownership") button brings up a dialog box telling 44you who owns the given file. The owner name will be of the form : 45 46tt("SERVER\user (Long name)") 47 48Where tt(SERVER) is the NetBIOS name of the Samba server, tt(user) 49is the user name of the UNIX user who owns the file, and tt((Long name)) 50is the discriptive string identifying the user (normally found in the 51GECOS field of the UNIX password database). Click on the tt(Close) 52button to remove this dialog. 53 54If the parameter url(bf("nt acl support"))(smb.conf.5.html#ntaclsupport) 55is set to "false" then the file owner will be shown as the NT user 56tt("Everyone"). 57 58The tt(Take Ownership) button will not allow you to change the 59ownership of this file to yourself (clicking on it will display a 60dialog box complaining that the user you are currently logged onto 61the NT client cannot be found). The reason for this is that changing 62the ownership of a file is a privilaged operation in UNIX, available 63only to the em(root) user. As clicking on this button causes NT to 64attempt to change the ownership of a file to the current user logged 65into the NT client this will not work with Samba at this time. 66 67There is an NT chown command that will work with Samba and allow 68a user with Administrator privillage connected to a Samba 2.0.4 69server as root to change the ownership of files on both a local NTFS 70filesystem or remote mounted NTFS or Samba drive. This is available 71as part of the bf(Seclib) NT security library written by Jeremy 72Allison of the Samba Team, available from the main Samba ftp site. 73 74bf(Viewing file or directory permissions)nl() 75bf(-------------------------------------) 76 77The third button is the tt("Permissions") button. Clicking on this 78brings up a dialog box that shows both the permissions and the UNIX 79owner of the file or directory. The owner is displayed in the form : 80 81tt("SERVER\user (Long name)") 82 83Where tt(SERVER) is the NetBIOS name of the Samba server, tt(user) 84is the user name of the UNIX user who owns the file, and tt((Long name)) 85is the discriptive string identifying the user (normally found in the 86GECOS field of the UNIX password database). 87 88If the parameter url(bf("nt acl support"))(smb.conf.5.html#ntaclsupport) 89is set to "false" then the file owner will be shown as the NT user 90tt("Everyone") and the permissions will be shown as NT tt("Full Control"). 91 92The permissions field is displayed differently for files and directories, 93so I'll describe the way file permissions are displayed first. 94 95bf(File Permissions)nl() 96bf(----------------) 97 98The standard UNIX user/group/world triple and the correspinding 99"read", "write", "execute" permissions triples are mapped by Samba 100into a three element NT ACL with the 'r', 'w', and 'x' bits mapped 101into the corresponding NT permissions. The UNIX world permissions are mapped 102into the global NT group tt(Everyone), followed by the list of permissions 103allowed for UNIX world. The UNIX owner and group permissions 104are displayed as an NT tt(user) icon and an NT tt(local group) icon 105respectively followed by the list of permissions allowed for the 106UNIX user and group. 107 108As many UNIX permission sets don't map into common NT names such as 109tt("read"), tt("change") or tt("full control") then usually the permissions 110will be prefixed by the words tt("Special Access") in the NT display 111list. 112 113But what happens if the file has no permissions allowed for a 114particular UNIX user group or world component ? In order to 115allow "no permissions" to be seen and modified then Samba overloads 116the NT tt("Take Ownership") ACL attribute (which has no meaning in 117UNIX) and reports a component with no permissions as having the NT 118tt("O") bit set. This was chosen of course to make it look like a 119zero, meaning zero permissions. More details on the decision behind 120this will be given below. 121 122bf(Directory Permissions)nl() 123bf(---------------------) 124 125Directories on an NT NTFS file system have two different sets of 126permissions. The first set of permissions is the ACL set on the 127directory itself, this is usually displayed in the first set of 128parentheses in the normal tt("RW") NT style. This first set of 129permissions is created by Samba in exactly the same way as normal 130file permissions are, described above, and is displayed in the 131same way. 132 133The second set of directory permissions has no real meaning in the 134UNIX permissions world and represents the tt("inherited") permissions 135that any file created within this directory would inherit. 136 137Samba synthesises these inherited permissions for NT by returning as 138an NT ACL the UNIX permission mode that a new file created by Samba 139on this share would receive. 140 141bf(Modifying file or directory permissions)nl() 142bf(---------------------------------------) 143 144Modifying file and directory permissions is as simple as changing 145the displayed permissions in the dialog box, and clicking the tt(OK) 146button. However, there are limitations that a user needs to be aware 147of, and also interactions with the standard Samba permission masks 148and mapping of DOS attributes that need to also be taken into account. 149 150If the parameter url(bf("nt acl support"))(smb.conf.5.html#ntaclsupport) 151is set to "false" then any attempt to set security permissions will 152fail with an tt("Access Denied") message. 153 154The first thing to note is that the tt("Add") button will not return 155a list of users in Samba 2.0.4 (it will give an error message of 156tt("The remote proceedure call failed and did not execute")). This 157means that you can only manipulate the current user/group/world 158permissions listed in the dialog box. This actually works quite well 159as these are the only permissions that UNIX actually has. 160 161If a permission triple (either user, group, or world) is removed from 162the list of permissions in the NT dialog box, then when the tt("OK") 163button is pressed it will be applied as "no permissions" on the UNIX 164side. If you then view the permissions again the "no permissions" entry 165will appear as the NT tt("O") flag, as described above. This allows you 166to add permissions back to a file or directory once you have removed 167them from a triple component. 168 169As UNIX supports only the "r", "w" and "x" bits of an NT ACL 170then if other NT security attributes such as "Delete access" 171are selected then they will be ignored when applied on the 172Samba server. 173 174When setting permissions on a directory the second set of permissions 175(in the second set of parentheses) is by default applied to all 176files within that directory. If this is not what you want you 177must uncheck the tt("Replace permissions on existing files") checkbox 178in the NT dialog before clicking tt("OK"). 179 180If you wish to remove all permissions from a user/group/world 181component then you may either highlight the component and click 182the tt("Remove") button, or set the component to only have the special 183tt("Take Ownership") permission (dsplayed as tt("O")) highlighted. 184 185bf(Interaction with the standard Samba create mask parameters)nl() 186bf(----------------------------------------------------------) 187 188Note that with Samba 2.0.5 there are four new parameters to 189control this interaction. 190 191These are : 192 193tt(security mask) 194tt(force security mode) 195tt(directory security mask) 196tt(force directory security mode) 197 198Once a user clicks tt("OK") to apply the permissions Samba maps 199the given permissions into a user/group/world r/w/x triple set, 200and then will check the changed permissions for a file against 201the bits set in the url(bf("security mask"))(smb.conf.5.html#securitymask) 202parameter. Any bits that were changed that are not set to '1' 203in this parameter are left alone in the file permissions. 204 205Essentially, zero bits in the url(bf("security mask"))(smb.conf.5.html#securitymask) 206mask may be treated as a set of bits the user is em(not) allowed to change, 207and one bits are those the user is allowed to change. 208 209If not set explicitly this parameter is set to the same value as the 210url(bf("create mask"))(smb.conf.5.html#createmask) parameter to provide compatibility 211with Samba 2.0.4 where this permission change facility was introduced. 212To allow a user to modify all the user/group/world permissions on a file, 213set this parameter to 0777. 214 215Next Samba checks the changed permissions for a file against the 216bits set in the url(bf("force security mode"))(smb.conf.5.html#forcesecuritymode) 217parameter. Any bits that were changed that correspond to bits set 218to '1' in this parameter are forced to be set. 219 220Essentially, bits set in the url(bf("force security mode"))(smb.conf.5.html#forcesecuritymode) 221parameter may be treated as a set of bits that, when modifying security on a file, the 222user has always set to be 'on'. 223 224If not set explicitly this parameter is set to the same value as the 225url(bf("force create mode"))(smb.conf.5.html#forcecreatemode) parameter to provide compatibility 226with Samba 2.0.4 where the permission change facility was introduced. 227To allow a user to modify all the user/group/world permissions on a file, 228with no restrictions set this parameter to 000. 229 230The url(bf("security mask"))(smb.conf.5.html#securitymask) and 231url(bf("force security mode"))(smb.conf.5.html#forcesecuritymode) parameters 232are applied to the change request in that order. 233 234For a directory Samba will perform the same operations as described above 235for a file except using the parameter url(bf("directory security mask"))(smb.conf.5.html#directorysecuritymask) 236instead of url(bf("security mask"))(smb.conf.5.html#securitymask), and 237url(bf("force directory security mode"))(smb.conf.5.html#forcedirectorysecuritymode) parameter instead 238of url(bf("force security mode"))(smb.conf.5.html#forcesecuritymode). 239 240The url(bf("directory security mask"))(smb.conf.5.html#directorysecuritymask) 241parameter by default is set to the same value as the url(bf("directory mask"))(smb.conf.5.html#directorymask) 242parameter and the url(bf("force directory security mode"))(smb.conf.5.html#forcedirectorysecuritymode) 243parameter by default is set to the same value as the 244iurl(bf("force directory mode"))(smb.conf.5.html#forcedirectorymode) parameter 245to provide compatibility with Samba 2.0.4 where the permission change facility was introduced. 246 247In this way Samba enforces the permission restrictions that an administrator 248can set on a Samba share, whilst still allowing users to modify the 249permission bits within that restriction. 250 251If you want to set up a share that allows users full control 252in modifying the permission bits on their files and directories and 253doesn't force any particular bits to be set 'on', then set the following 254parameters in the url(bf(smb.conf.5))(smb.conf.5.html) file in 255that share specific section : 256 257tt(security mask = 0777) 258tt(force security mode = 0) 259tt(directory security mask = 0777) 260tt(force directory security mode = 0) 261 262As described, in Samba 2.0.4 the parameters : 263 264tt(create mask) 265tt(force create mode) 266tt(directory mask) 267tt(force directory mode) 268 269were used instead of the parameters discussed here. 270 271bf(Interaction with the standard Samba file attribute mapping)nl() 272bf(----------------------------------------------------------) 273 274Samba maps some of the DOS attribute bits (such as "read only") 275into the UNIX permissions of a file. This means there can be a 276conflict between the permission bits set via the security dialog 277and the permission bits set by the file attribute mapping. 278 279One way this can show up is if a file has no UNIX read access 280for the owner it will show up as "read only" in the standard 281file attributes tabbed dialog. Unfortunately this dialog is 282the same one that contains the security info in another tab. 283 284What this can mean is that if the owner changes the permissions 285to allow themselves read access using the security dialog, clicks 286tt("OK") to get back to the standard attributes tab dialog, and 287then clicks tt("OK") on that dialog, then NT will set the file 288permissions back to read-only (as that is what the attributes 289still say in the dialog). This means that after setting permissions 290and clicking tt("OK") to get back to the attributes dialog you 291should always hit tt("Cancel") rather than tt("OK") to ensure 292that your changes are not overridden. 293