This chapter continues our discussion of configuring Samba from Chapter 6. We will cover some more advanced issues regarding the integration of Unix and Windows filesystems, including hidden files, Unix links, file permissions, name mangling, case sensitivity of filenames, file locking, opportunistic locking (oplocks), connection scripts, supporting Microsoft Dfs (Distributed filesystem) shares, and using NIS home directories.
Sometimes you need to ensure that a user cannot see or access a file at all. Other times, you don't want to keep users from accessing a file—you just want to hide it when they view the contents of the directory. On Windows systems, an attribute of files allows them to be hidden from a folder listing. With Unix, the traditional way of hiding files in a directory is to use a dot (.) as the first character in the filename. This prevents items such as configuration files from being seen when performing an ordinary ls command. Keeping a user from accessing a file at all, however, involves working with permissions on files and directories.
The first option we should discuss is the Boolean hide dot files. When it is set to yes, Samba reports files beginning with a period (.) as having their hidden attribute set. If the user has chosen to show all hidden files while browsing (e.g., using the Folder Options menu item under the View menu in Windows 98), he will still be able to see the files, although his icons will appear "ghosted," or slightly grayed-out. If the client is configured not to show hidden files, the files will not appear at all.
Instead of simply hiding files beginning with a dot, you can also specify a string pattern to Samba for files to hide, using the hide files option. For example, let's assume you specified the following in our example [data] share:
[data] hide files = /*.java/*README*/
If you want to prevent users from seeing files completely, you can instead use the veto files option. This option, which takes the same syntax as the hide files option, specifies a list of files that should never be seen by the user. For example, let's change the [data] share to the following:
[data] veto files = /*.java/*README*/
We need to address one other question. What happens if the user tries to delete a directory that contains vetoed files? This is where the delete veto files option comes in. If this Boolean option is set to yes, the user can delete both the regular files and the vetoed files in the directory, and the directory itself is removed. If the option is set to no, the user cannot delete the vetoed files, and consequently the directory is not deleted either. From the user's perspective, the directory appears empty, but cannot be removed.
The dont descend directive specifies a list of directories whose contents Samba should not make visible. Note that we say contents, not the directory itself. Users can enter a directory marked as such, but they are prohibited from descending the directory tree any farther—they always see an empty folder. For example, let's use this option with a more basic form of the share that we defined earlier in the chapter:
[data] dont descend = config defaults
In addition, let's assume that the /home/samba/data directory has the following contents:
drwxr-xr-x 6 tom users 1024 Jun 13 09:24 . drwxr-xr-x 8 root root 1024 Jun 10 17:53 .. -rw-r--r-- 2 tom users 1024 Jun 9 11:43 README drwxr-xr-x 3 tom users 1024 Jun 13 09:28 config drwxr-xr-x 3 tom users 1024 Jun 13 09:28 defaults drwxr-xr-x 3 tom users 1024 Jun 13 09:28 market
If the user then connects to the share, she would see the directories in the share. However, the contents of the /config and /defaults directories would appear empty to her, even if other folders or files existed in them. In addition, users cannot write any data to the folder (which prevents them from creating a file or folder with the same name as one that is already there but invisible). If a user attempts to do so, she will receive an "Access Denied" message. The dont descend option is an administrative option—not a security option—and is not a substitute for good file permissions.
[data] follow symlinks = no
$ echo "This is a test" >hello.txt $ ln -s hello.txt hello-link.txt
This results in the text file hello.txt and a symbolic link to it called hello-link.txt. Normally, if you double-click either one, you will receive a file that has the text "This is a test" inside of it. However, with the follow symlinks option set to no, you will receive an error dialog if you double-click hello-link.txt.
The wide links option, if set to no, prevents the client user from following symbolic links that point outside the shared directory tree. For example, let's assume that we modified the [data] share as follows:
[data] follow symlinks = yes wide links = no
As long as the follow symlinks option is disabled, Samba will refuse to follow any symbolic links outside the current share tree. If we create a file outside the share (for example, in someone's home directory) and then create a link to it in the share as follows:
ln -s ~tom/datafile ./datafile
Table 8-1 shows a breakdown of the options we discussed earlier. We recommend the defaults for most, except those listed in the following descriptions.
Option |
Parameters |
Function |
Default |
Scope |
---|---|---|---|---|
dont descend |
string (list of directories) |
Indicates a list of directories whose contents Samba should make invisible to clients. |
None |
Share |
follow symlinks |
Boolean |
If set to no, will not honor symbolic links. |
yes |
Share |
getwd cache |
Boolean |
If set to yes, will use a cache for getwd( ) calls. |
yes |
Global |
wide links |
Boolean |
If set to yes, will follow symbolic links outside the share. |
yes |
Share |
hide dot files |
Boolean |
If set to yes, treats Unix hidden files as hidden files in Windows. |
yes |
Share |
hide files |
string (list of files) |
List of file patterns to treat as hidden. |
None |
Share |
veto files |
string (list of files) |
List of file patterns to never show. |
None |
Share |
delete veto files |
Boolean |
If set to yes, will delete files matched by veto files when the directory they reside in is deleted. |
no |
Share |
The dont descend option can be used to specify various directories that should appear empty to the client. Note that the directory itself will still appear. However, Samba will not show any of the contents of the directory to the client user. This is not a good option to use as a security feature; it is really meant only as a convenience to keep users from casually browsing into directories that might have sensitive files. See our example earlier in this section.
The hide dot files option hides any files on the server that begin with a dot (.) character to mimic the functionality behind several shell commands that are present on Unix systems. Like hide files, those files that begin with a dot have the DOS hidden attribute set, which doesn't guarantee that a client cannot view them. The default value for this option is yes.
The hide files option provides one or more directory or filename patterns to Samba. Any file matching this pattern will be treated as a hidden file from the perspective of the client. Note that this simply means that the DOS hidden attribute is set, which might or might not mean that the user can actually see it while browsing.
hide files = /.jav*/README.???/
veto files = /*config/*default?/
This option is primarily administrative and is not a substitute for good file permissions.
This option tells Samba to delete vetoed files when a user attempts to delete the directory in which they reside. The default value is no. This means that if a user tries to delete a directory that contains a vetoed file, the file (and the directory) will not be deleted. Instead, the directory remains and appears empty from the perspective of the user. If set to yes, the directory and the vetoed files will be deleted.
Originally, DOS was not intended to be a multiuser, networked operating system. Unix, on the other hand, was designed for multiple users from the start. Consequently, Samba must not only be aware of, but also provide special solutions for, inconsistencies and gaps in coverage between the two filesystems. One of the biggest gaps is how Unix and DOS handle permissions on files.
-rwxr--r-- 1 tom users 2014 Apr 13 14:11 access.conf
Windows, on the other hand, has four principal bits that it uses with any file: read-only, system, hidden, and archive. You can view these bits by right-clicking the file and choosing the Properties menu item. You should see a dialog similar to Figure 8-1.[1]
The definition of each bit follows:
The file's contents can be read by a user but cannot be written to.
This file has a specific purpose required by the operating system.
This file has been touched since the last DOS backup was performed on it.
Three Samba options decide whether the bits are mapped: map archive, map system , and map hidden. These options map the archive, system, and hidden attributes to the owner, group, and world execute bits of the file, respectively. You can add these options to the [data] share, setting each of their values as follows:
[data] map archive = yes map system = yes map hidden = yes
Figure 8-2 summarizes the Unix permission bits and illustrates how Samba maps those bits to DOS attributes. Note that the group read/write and world read/write bits do not directly translate to a DOS attribute, but they still retain their original Unix definitions on the Samba server.
File and directory creation masks are similar to umasks you have probably encountered while working with Unix systems. They are used to help define the permissions that will be assigned to a file or directory at the time it is created. Samba's masks work differently in that the bits that can be set are set in the creation mask, while in Unix umasks, the bits cannot be set are set in the umask. We think you will find Samba's method to be much more intuitive. Once in a while you might need to convert between a Unix umask and the equivalent Samba mask. It is simple: one is just the bitwise complement of the other. For example, an octal umask of 0022 has the same effect as a Samba mask of 0755.
Unix umasks are set on a user-by-user basis, usually while executing the GUI's or command-line shell's startup scripts. When users connect to a Samba share from a network client, these scripts are not executed, so Samba supplies the ability to set the creation masks for files and directories. By default, this is done on a share-by-share basis, although you can use the include parameter in the Samba configuration file (as explained in Chapter 6) to assign masks on a user-by-user basis, thus matching conventional Unix behavior.
To show how Samba's create masks work, suppose we have a Windows Me user connecting to his Unix home directory through Samba, and Samba is configured with create mask = 777 in the [homes] share. With this value, create mask will not affect the bits that are set on new files. If the user creates a file with Wordpad, it will appear in the Unix filesystem like this:
$ ls -l file.doc -rwxrw-rw- 1 jay jay 0 Sep 21 11:02 file.doc
Wordpad created the file with read/write permissions (i.e., the MS-DOS read-only attribute was not set), so Samba mapped the MS-DOS attributes to Unix read/write permissions for user, group, and other. The execute bit is set for the owner because by default, the map archive parameter is set to yes. The other execute bits are not set because map system and map hidden are set to no by default. You can customize this behavior as you see fit, and unless you do backups from MS-DOS or Windows systems, you might want to specify map archive = no to avoid Windows files from appearing as executables on the Unix system.
Now suppose we set create mask to have an effect. For example:
[homes] create mask = 664
$ ls -l file.doc -rw-rw-r-- 1 jay jay 0 Sep 22 16:38 file.doc
The directory mask option works similarly, masking permissions for newly created directories. The following example will allow the permissions of a newly created directory to be, at most, 755:
[data] directory mask = 755
In the same spirit, if you wish to set explicitly the Unix user and group attributes of a file created on the Windows side, you can use the force user and force group options. For example:
[data] create mask = 744 directory mask = 755 force user = joe force group = accounting
Normally, this is harmless. Windows programs don't try to remove read-only files because they know it's a bad idea. However, a number of source-code control programs—which were first written for Unix—run on Windows and require the ability to delete read-only files. Samba permits this behavior with the delete readonly option. To enable this functionality, set the option to yes:
[data] delete readonly = yes
The options for file and directory permissions are summarized in Table 8-2; each option is then described in detail.
Option |
Parameters |
Function |
Default |
Scope |
---|---|---|---|---|
create mask (create mode) |
numeric |
Maximum permissions for files created by Samba. |
0744 |
Share |
directory mask (directory mode) |
numeric |
Maximum permissions for directories created by Samba. |
0744 |
Share |
force create mode |
numeric |
Forces the specified permissions (bitwise or) for directories created by Samba. |
0000 |
Share |
force directory mode |
numeric |
Forces the specified permissions (bitwise or) for directories created by Samba. |
0000 |
Share |
force group (group) |
string ( group name) |
Effective group for a user accessing this share. |
None |
Share |
force user |
string (username) |
Effective username for a user accessing this share. |
None |
Share |
delete readonly |
Boolean |
Allows a user to delete a read-only file from a writable directory. |
no |
Share |
map archive |
Boolean |
Preserve DOS archive attribute in user execute bit (0100). |
yes |
Share |
map system |
Boolean |
Preserve DOS system attribute in group execute bit (0010). |
no |
Share |
map hidden |
Boolean |
Preserve DOS hidden attribute in world execute bit (0001). |
no |
Share |
inherit permissions |
Boolean |
If yes, permissions on new files and directories are inherited from parent directory. |
no |
Share |
The force user option assigns a static user ID that will be used on all connections to a share after the client has successfully authenticated. This assigns a specific user to each new file or directory created from an SMB client.