UNIX Permission Bits and Windows NT Access Control Lists

Viewing and changing UNIX permissions using the NT - security dialogs

New in the Samba 2.0.4 release is the ability for Windows - NT clients to use their native security settings dialog box to - view and modify the underlying UNIX permissions.

Note that this ability is careful not to compromise - the security of the UNIX host Samba is running on, and - still obeys all the file permission rules that a Samba - administrator can set.

In Samba 2.0.4 and above the default value of the - parameter nt acl support has been changed from - false to true, so - manipulation of permissions is turned on by default.

How to view file security on a Samba share

From an NT 4.0 client, single-click with the right - mouse button on any file or directory in a Samba mounted - drive letter or UNC path. When the menu pops-up, click - on the Properties entry at the bottom of - the menu. This brings up the normal file properties dialog - box, but with Samba 2.0.4 this will have a new tab along the top - marked Security. Click on this tab and you - will see three buttons, Permissions, - Auditing, and Ownership. - The Auditing button will cause either - an error message A requested privilege is not held - by the client to appear if the user is not the - NT Administrator, or a dialog which is intended to allow an - Administrator to add auditing requirements to a file if the - user is logged on as the NT Administrator. This dialog is - non-functional with a Samba share at this time, as the only - useful button, the Add button will not currently - allow a list of users to be seen.

Viewing file ownership

Clicking on the "Ownership" button - brings up a dialog box telling you who owns the given file. The - owner name will be of the form :

"SERVER\user (Long name)"

Where SERVER is the NetBIOS name of - the Samba server, user is the user name of - the UNIX user who owns the file, and (Long name) - is the descriptive string identifying the user (normally found in the - GECOS field of the UNIX password database). Click on the Close - button to remove this dialog.

If the parameter nt acl support - is set to false then the file owner will - be shown as the NT user "Everyone".

The Take Ownership button will not allow - you to change the ownership of this file to yourself (clicking on - it will display a dialog box complaining that the user you are - currently logged onto the NT client cannot be found). The reason - for this is that changing the ownership of a file is a privileged - operation in UNIX, available only to the root - user. As clicking on this button causes NT to attempt to change - the ownership of a file to the current user logged into the NT - client this will not work with Samba at this time.

There is an NT chown command that will work with Samba - and allow a user with Administrator privilege connected - to a Samba 2.0.4 server as root to change the ownership of - files on both a local NTFS filesystem or remote mounted NTFS - or Samba drive. This is available as part of the Seclib - NT security library written by Jeremy Allison of - the Samba Team, available from the main Samba ftp site.

Viewing file or directory permissions

The third button is the "Permissions" - button. Clicking on this brings up a dialog box that shows both - the permissions and the UNIX owner of the file or directory. - The owner is displayed in the form :

"SERVER\user (Long name)"

If the parameter nt acl support - is set to false then the file owner will - be shown as the NT user "Everyone" and the - permissions will be shown as NT "Full Control".

The permissions field is displayed differently for files - and directories, so I'll describe the way file permissions - are displayed first.

File Permissions

The standard UNIX user/group/world triple and - the corresponding "read", "write", "execute" permissions - triples are mapped by Samba into a three element NT ACL - with the 'r', 'w', and 'x' bits mapped into the corresponding - NT permissions. The UNIX world permissions are mapped into - the global NT group Everyone, followed - by the list of permissions allowed for UNIX world. The UNIX - owner and group permissions are displayed as an NT - user icon and an NT local - group icon respectively followed by the list - of permissions allowed for the UNIX user and group.

As many UNIX permission sets don't map into common - NT names such as "read", "change" or "full control" then - usually the permissions will be prefixed by the words "Special Access" in the NT display list.

But what happens if the file has no permissions allowed - for a particular UNIX user group or world component ? In order - to allow "no permissions" to be seen and modified then Samba - overloads the NT "Take Ownership" ACL attribute - (which has no meaning in UNIX) and reports a component with - no permissions as having the NT "O" bit set. - This was chosen of course to make it look like a zero, meaning - zero permissions. More details on the decision behind this will - be given below.

Directory Permissions

Directories on an NT NTFS file system have two - different sets of permissions. The first set of permissions - is the ACL set on the directory itself, this is usually displayed - in the first set of parentheses in the normal "RW" - NT style. This first set of permissions is created by Samba in - exactly the same way as normal file permissions are, described - above, and is displayed in the same way.

The second set of directory permissions has no real meaning - in the UNIX permissions world and represents the "inherited" permissions that any file created within - this directory would inherit.

Samba synthesises these inherited permissions for NT by - returning as an NT ACL the UNIX permission mode that a new file - created by Samba on this share would receive.

Modifying file or directory permissions

Modifying file and directory permissions is as simple - as changing the displayed permissions in the dialog box, and - clicking the OK button. However, there are - limitations that a user needs to be aware of, and also interactions - with the standard Samba permission masks and mapping of DOS - attributes that need to also be taken into account.

If the parameter nt acl support - is set to false then any attempt to set - security permissions will fail with an "Access Denied" - message.

The first thing to note is that the "Add" - button will not return a list of users in Samba 2.0.4 (it will give - an error message of "The remote procedure call failed - and did not execute"). This means that you can only - manipulate the current user/group/world permissions listed in - the dialog box. This actually works quite well as these are the - only permissions that UNIX actually has.

If a permission triple (either user, group, or world) - is removed from the list of permissions in the NT dialog box, - then when the "OK" button is pressed it will - be applied as "no permissions" on the UNIX side. If you then - view the permissions again the "no permissions" entry will appear - as the NT "O" flag, as described above. This - allows you to add permissions back to a file or directory once - you have removed them from a triple component.

As UNIX supports only the "r", "w" and "x" bits of - an NT ACL then if other NT security attributes such as "Delete - access" are selected then they will be ignored when applied on - the Samba server.

When setting permissions on a directory the second - set of permissions (in the second set of parentheses) is - by default applied to all files within that directory. If this - is not what you want you must uncheck the "Replace - permissions on existing files" checkbox in the NT - dialog before clicking "OK".

If you wish to remove all permissions from a - user/group/world component then you may either highlight the - component and click the "Remove" button, - or set the component to only have the special "Take - Ownership" permission (displayed as "O" - ) highlighted.

Interaction with the standard Samba create mask - parameters

Note that with Samba 2.0.5 there are four new parameters - to control this interaction. These are :

security mask

force security mode

directory security mask

force directory security mode

Once a user clicks "OK" to apply the - permissions Samba maps the given permissions into a user/group/world - r/w/x triple set, and then will check the changed permissions for a - file against the bits set in the - security mask parameter. Any bits that - were changed that are not set to '1' in this parameter are left alone - in the file permissions.

Essentially, zero bits in the security mask - mask may be treated as a set of bits the user is not - allowed to change, and one bits are those the user is allowed to change. -

If not set explicitly this parameter is set to the same value as - the create mask - parameter to provide compatibility with Samba 2.0.4 - where this permission change facility was introduced. To allow a user to - modify all the user/group/world permissions on a file, set this parameter - to 0777.

Next Samba checks the changed permissions for a file against - the bits set in the force security mode parameter. Any bits - that were changed that correspond to bits set to '1' in this parameter - are forced to be set.

Essentially, bits set in the force security mode - parameter may be treated as a set of bits that, when - modifying security on a file, the user has always set to be 'on'.

If not set explicitly this parameter is set to the same value - as the force - create mode parameter to provide compatibility - with Samba 2.0.4 where the permission change facility was introduced. - To allow a user to modify all the user/group/world permissions on a file - with no restrictions set this parameter to 000.

The security mask and force - security mode parameters are applied to the change - request in that order.

For a directory Samba will perform the same operations as - described above for a file except using the parameter directory security mask instead of security - mask, and force directory security mode - parameter instead of force security mode -.

The directory security mask parameter - by default is set to the same value as the directory mask - parameter and the force directory security - mode parameter by default is set to the same value as - the force directory mode parameter to provide - compatibility with Samba 2.0.4 where the permission change facility - was introduced.

In this way Samba enforces the permission restrictions that - an administrator can set on a Samba share, whilst still allowing users - to modify the permission bits within that restriction.

If you want to set up a share that allows users full control - in modifying the permission bits on their files and directories and - doesn't force any particular bits to be set 'on', then set the following - parameters in the smb.conf(5) - file in that share specific section :

security mask = 0777

force security mode = 0

directory security mask = 0777

force directory security mode = 0

As described, in Samba 2.0.4 the parameters :

create mask

force create mode

directory mask

force directory mode

were used instead of the parameters discussed here.

Interaction with the standard Samba file attribute - mapping

Samba maps some of the DOS attribute bits (such as "read - only") into the UNIX permissions of a file. This means there can - be a conflict between the permission bits set via the security - dialog and the permission bits set by the file attribute mapping. -

One way this can show up is if a file has no UNIX read access - for the owner it will show up as "read only" in the standard - file attributes tabbed dialog. Unfortunately this dialog is - the same one that contains the security info in another tab.

What this can mean is that if the owner changes the permissions - to allow themselves read access using the security dialog, clicks - "OK" to get back to the standard attributes tab - dialog, and then clicks "OK" on that dialog, then - NT will set the file permissions back to read-only (as that is what - the attributes still say in the dialog). This means that after setting - permissions and clicking "OK" to get back to the - attributes dialog you should always hit "Cancel" - rather than "OK" to ensure that your changes - are not overridden.