8.3 Windows NT2000XP ACLs

8.3 Windows NT/2000/XP ACLs

Unix and Windows have different security models, and Windows NT/2000/XP has a security model that is different from Windows 95/98/Me. One area in which this is readily apparent is file protections . On Unix systems, the method used has traditionally been the 9-bit " user , group , other" system, in which read, write, and execute bits can be set separately for the owner of the file, the groups to which the owner belongs, and everyone else, respectively.

Windows 95/98/Me has a file-protection system that is essentially no protection at all. This family of operating systems was developed from MS-DOS, which was implemented as a non-networked, single-user system. Multiuser security simply was never added. One apparent exception to this is user-level security for shared files, which we will discuss in Chapter 9. Here, separate access permissions can be assigned to individual network client users or groups. However, user-level security on Windows 95/98/Me systems requires a Windows NT/2000 or Samba server to perform the actual authentication.

On Windows NT/2000/XP, user-level security is an extension of the native file security model, which involves access control lists (ACLs). This system is somewhat more extensive than the Unix security model, allowing the access rights on individual files to be set separately for any number of individual users and/or any number of arbitrary groups of users. Figure 8-3, Figure 8-4, and Figure 8-5 show the dialog boxes on a Windows 2000 system in which the ACL is set for a file. By right-clicking a file's icon and selecting Properties, then selecting the Security tab, we get to the dialog box shown in Figure 8-3. Here, we can set the basic permissions for a file, which are similar to Unix permissions, although not identical.

Figure 8-3. The Security tab of the file Properties dialog

By clicking the Advanced tab, we can bring up the dialog box shown in Figure 8-4, which shows the list of access control entries (ACEs) in the ACL. In this dialog, ACEs can be added to or deleted from the ACL, or an existing ACE can be viewed and modified. Each ACE either allows or denies a set of permissions for a specific user or group.

Figure 8-4. The Permissions tab of the Access Control Settings dialog

Figure 8-5. Permission Entry dialog, showing the settings of an ACE

Figure 8-5 shows the dialog box for adding an ACE. As you can see, there are more options for permissions in an ACL than with the permission bits on typical Unix systems. You can learn more about these settings in Essential Windows NT System Administration , published by O'Reilly.

In a networked environment where a Samba server is serving files to Windows NT/2000/XP clients , Samba has to map Unix permissions for files and directories to Windows NT/2000/XP access control lists. When a Windows NT/2000/XP client accesses a shared file or directory on a Samba server, Samba translates the object's ownership, group, and permissions into an ACL and returns them to the client.

Figure 8-6 shows the Properties dialog box for the file shopping_list.doc that resides on the Samba server.

Figure 8-6. The Properties dialog for a file on the Samba server

From Unix, this file appears as:

 $  ls -l shopping_list.doc  -rw-------    1 adilia   users          49 Mar 29 11:58 shopping_list.doc 

Notice that because the file has read permissions for the owner, the Read-only checkbox will show as cleared, even though the user on the Windows client (who is not adilia in this example) does not have read access permissions. The checkboxes here show only DOS attributes. By clicking the Security tab, we can start to examine the ACLs, as shown in Figure 8-7.

Figure 8-7. The Security tab of the Properties dialog for a file on the Samba server

The owner of the file ( adilia ) is shown as one entry, while the group ( users ) and other permissions are presented as the groups called users and Everyone . Clicking one of the items in the upper windows causes the simplified view of the permissions in that item to appear in the bottom window. Here, the read/write permissions for adilia appear in a manner that makes the security model of Unix and Windows seem similar. However, clicking the Advanced . . . button brings up the additional dialog box shown in Figure 8-8.

Figure 8-8. The Access Control Settings dialog for a file on the Samba server

In this dialog box, we see the actual ACL of the file. The ACEs for users and Everyone are listed with Take Ownership in the Permission column. This is a trick used by Samba for ACLs that have no permissions on the Unix side. On Windows, an ACL with nothing set results in no ACL at all, so Samba sets the Take Ownership permission to make sure that all the ACLs corresponding to the Unix "user, group, other" permissions will show up on Windows. The Take Ownership permission has no corresponding Unix attribute, so the setting on Windows does not affect the actual file on the Unix system in any way. Although Windows client users might be misled into thinking they can take ownership of the file (that is, change the ownership of the file to themselves ), an actual attempt to do so will fail.

The Permissions column for the adilia ACL is listed as Special because Samba reports permissions for the file that do not correspond to settings for which Windows has a more descriptive name . Clicking the entry and then clicking the View/Edit . . . button brings up the dialog box shown in Figure 8-9, in which the details of the ACL permissions can be viewed and perhaps modified.

Figure 8-9. Permission Entry dialog for a file served by Samba

We say "perhaps" here because checking or unchecking boxes in this dialog box might not result in settings that Samba is able to map back into the Unix security model. When a user attempts to modify a setting (either permissions or ownership) that she does not have authority to change, or does not correspond to a valid setting on the Unix system, Samba will respond with an error dialog or by quietly ignoring the unmappable settings.

The ACLs for a directory are slightly different. Figure 8-10 shows the ACL view after clicking the Advanced button.

Figure 8-10. The Access Control Settings dialog for a directory on the Samba server

Here, there are two ACLs each for users and Everyone . One ACL specifies the permissions for the directory itself, and the other specifies permissions for the directory's contents. When changing settings in the View/Edit... dialog, there is an extra drop-down menu to apply the settings either to just the directory or to some combination of the directory and the files and directories it contains. If settings are applied to more than just the directory, Samba will match the behavior of a Windows server and change the permissions on the contents of the directory, as specified in the dialog.

8.3.1 Unix ACLs

In most cases, users of Windows clients will find the Unix security model to be sufficient. However, in some cases, people might want the Samba server to support the full Windows ACL security model. Even if they don't need the fine-grained control over file and directory permissions, they might find Samba's translation between ACLs and Unix permissions to be a source of confusion or frustration.

When the underlying Unix host operating system supports POSIX.1e ACLs, Samba provides much better support of Windows NT/2000/XP ACLs. Versions of Unix that offer the necessary support include the following:

• Solaris 2.6 and later

• SGI Irix

• Linux, with Andreas Gr ¼nbacher's kernel patch from http://acl.bestbits.at that adds ACL support to the Linux ext2 and ext3 filesystems

• Linux, with the XFS filesystem

• AIX

• FreeBSD 5.0 and later

• HP/UX 11.0 and later, with the JFS 3.3 filesystem layout Version 4

If you are fortunate enough to have a Unix host operating system with ACL support already provided, all you need to do is recompile Samba using the --with-acl-support configure option, as we described in Chapter 2. If you are running Linux and need to patch your kernel, things are much more complicated. We suggest you refer to the documentation that comes with the patch for details on using it.

8.3.2 Configuration Options for ACLs

Table 8-3 shows the Samba configuration options for working with Windows NT/2000/XP access control lists.

Table 8-3. ACL configuration options

Option	Parameters	Function	Default	Scope
nt acl support	Boolean	If yes , allows users on Windows NT/2000/XP clients to modify ACL settings	yes	Share
security mask	numeric	Bitmask that allows or denies permission settings on files	0777	Share
force security mode	numeric	Bits that are always set when modifying file permissions	0000	Share
directory security mask	numeric	Bitmask that allows or denies permission settings on directories	0777	Share
force directory security mode	numeric	Bits that are always set when modifying directory permissions	0000	Share

8.3.2.1 nt acl support

This parameter defaults to yes , which allows users on Windows NT/2000/XP clients to modify ACL settings for files on the Samba server. When set to no , files show up as owned by Everyone , with permissions appearing as "Full Control". However, actual ownership and permissions are enforced as whatever they are set to on the Samba server, and the user on the Windows client cannot view or modify them with the dialog boxes used for managing ACLs.

When enabled, support for Windows NT/2000/XP ACLs is limited to whatever ownerships and permissions can map into valid users and permissions on the Samba server. If the server supports ACLs (either "out of the box" or with an additional patch to enhance the filesystem), Samba's ACL support more closely matches that of a Windows NT/2000/XP server.

8.3.2.2 security mask

Using the security mask option, it is possible to define which file permissions users can modify from Windows NT/2000/XP clients. This is for files only and not directories, which are handled with the directory security mask option. The parameter is assigned a numeric value that is a Unix-style permissions mask. For bits in the mask that are set, the client can modify the corresponding bits in the files' permissions. If the bit is zero, the client cannot modify that permission. For example, if security mask is set as:

 [data]     security mask = 0777 

the client can modify all the user/group/other permissions for the files in the share. This is the default. A value of would deny clients from changing any of the permissions, and setting security mask as:

 [data]     security mask = 0666 

would allow client users to modify the read and write permissions, but not the execute permissions.

Do not count on security mask for complete control because if the user can access the files on the Samba server through any other means (for example, by logging directly into the Unix host), he can modify the permissions using that method.

8.3.2.3 force security mode

The force security mode option can be used to define a set of permissions that are always set whenever the user on a Windows NT/2000/XP client modifies a file's permissions. (See the force directory security mode option for handling directories.)

Be careful to understand this properly. The mask given as the parameter's value is not necessarily equal to the resulting permissions on the file. The permissions that the client user attempts to modify are logically OR'd with the force security mode mask option, and any bits that are turned on will cause the file's corresponding permissions to be set. As an example, suppose force security mode is set in a share thusly:

 [data]     force security mode = 0440 

(This sets the read bit for owner and group, but not other.) If a user on a Windows NT/2000/XP client modifies an ACL on a file in the [data] share and attempts to remove all read permissions, the read permission for other ( Everyone ) will be removed, but the read permission for the owner and group will remain . Note that this parameter cannot force a permission bit to be turned off.

As with the security mask option, if a user can access the files in the share through any means other than Samba, she can easily work around Samba's enforcement of this parameter.

The default value of force security mode is 0000 , which allows users to remove any permission from files.

8.3.2.4 directory security mask

This option works exactly the same as the security mask option, except that it operates on directories rather than files. As with security mask , it has a default value of 0777 , which allows Windows NT/2000/XP client users to modify all Unix permissions on directories in the share.

8.3.2.5 force directory security mode

This option works exactly the same as the force security mode option, except that it operates on directories rather than files. It also has a default value of 0000 , which allows Windows NT/2000/XP client users to remove any permissions from directories in the share.