5.2.1 Hiding and Vetoing Files

There are some cases when we need to ensure that a user cannot see or access a file at all. Other times, we don't want to keep a user from accessing a file - we 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 precede them with a dot (.). This prevents items such as configuration files or defaults 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 or directories.

The first option we should discuss is the boolean hide dot files. This option does exactly what it says. When set to yes, the option treats files beginning with a period (.) as hidden. If set to no, those files are always shown. The important thing to remember is that the files are only hidden. 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), they will still be able to see the files, as shown in Figure 5.2.

Figure 5.2: Hidden files in the [data] share

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 that we specified the following in our example [data] share:

[data]
	path = /home/samba/data
	browseable = yes
	guest ok = yes
	writeable = yes
	case sensitive = no
	hide files = /*.java/*README*/

Each entry for this option must begin, end, or be separated from another with a slash ( / ) character, even if there is only one pattern listed. This convention allows spaces to appear in filenames. In this example, the share directory would appear as shown in Figure 5.3. Again, note that we have set the Windows 98 option to view hidden files for the window.

Figure 5.3: Hiding files based on filename patterns

If we want to prevent users from seeing files at all, we 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]
	path = /home/samba/data
	browseable = yes
	guest ok = yes
	writeable = yes
	case sensitive = no
	veto files = /*.java/*README*/

The syntax of this option is identical to the hide files configuration option: each entry must begin, end, or be separated from another with a slash (/) character, even if there is only one pattern listed. By doing so, the files hello.java and README will simply disappear from the directory, and the user will not be able to access them through SMB.

There is one other question that we need to address. 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 is allowed to delete both the regular files and the vetoed files in the directory, and the directory itself will be removed. If the option is set to no, the user will not be able to delete the vetoed files, and consequently the directory will not be deleted either. From the user's perspective, the directory will appear to be empty, but cannot be removed.

The dont descend directive specifies a list of directories whose contents Samba should not allow to be visible. Note that we say contents, not the directory itself. Users will be able to enter a directory marked as such, but they are prohibited from descending the directory tree any farther - they will 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]
	path = /home/samba/data
	browseable = yes
	guest ok = yes
	writeable = yes
	case sensitive = no
	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, he or she would see the directories shown in Figure 5.4. However, the contents of the /config and /defaults directories would appear empty to the user, 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, he or she will receive an "Access Denied" message. dont descend is an administrative option, not a security option, and is not a substitute for good file permissions.

Figure 5.4: Contents of the [data] share with dont descend

5.2.2 Links

DOS and NT filesystems don't have symbolic links; Windows 95/98/NT systems approximate this with "shortcuts" instead. Therefore, when a client tries to open a symbolic link on a Samba server share, Samba attempts to follow the link to find the real file and let the client open it, as if he or she were on a Unix machine. If you don't want to allow this, set the follow symlinks option:

[data]
	path = /home/samba/data
	browseable = yes
	guest ok = yes
	writeable = yes
	case sensitive = no
	follow symlinks = no

You can test this by creating a directory on the Unix server inside the share as the user that you are logging in with. Enter the following commands:

% mkdir hello; cd hello
% cat "This is a test" >hello.txt
% ln -s hello.txt "Link to hello"

This results in the two files shown in the window in Figure 5.5. Normally, if you click on either one, you will receive a file which has the text "This is a test" inside of it. However, with the follow symlinks option set to no, you should receive an error similar to the dialog in Figure 5.5 if you click on "Link to hello."

Figure 5.5: An error dialog trying to follow symbolic links when forbidden by Samba

Finally, let's discuss the wide links option. This option, if set to yes, allows the client user to follow symbolic links that point outside the shared directory tree, including files or directories at the other end of the link. For example, let's assume that we modified the [data] share as follows:

[data]
	path = /home/samba/data
	browseable = yes
	guest ok = yes
	writeable = yes
	case sensitive = no
	follow symlinks = yes
	wide links = yes

As long as the follow symlinks option is enabled, this will cause Samba to follow all 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

then you will be able to open the file in Tom's directory as per the target file's permissions.

5.2.3 Filesystem Options

Table 5.4 shows a breakdown of the options we discussed earlier. We recommend the defaults for most, except those listed in the following descriptions.

rcollins:/KaBfco47Rer5:500:500:Robert Collins:
/home/rcollins:/bin/ksh

[global]
	unix realname = yes

[global]
	getwd cache = no

hide files = /.jav*/README.???/

veto files = /*config/*default?/