Chapter 8. Advanced Disk Shares

File Permissions and Attributes on MS-DOS and Unix

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.

Let's take a look at how Unix assigns permissions. +All Unix files have read, write, and execute bits for three +classifications of users: owner, group, and world. These permissions +can be seen at the extreme lefthand side when an ls +-al command is issued in a Unix directory. For example:

-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]

+ +

Figure 8-1. DOS and Windows file properties

The definition of each bit follows:

Read-only: +
The file's contents can be read by a user but cannot +be written to.
+
System: +
This file has a specific purpose required by the operating system.
+
Hidden: +
This file has been marked to be invisible to the user, unless the +operating system is explicitly set to show it.
+
Archive: +
This file has been touched since the last DOS backup was performed on +it.
+

Note that there is no bit to specify that a file is executable. DOS +and Windows NT filesystems identify executable files by giving them +the extensions .exe, .com, +.cmd, or .bat.

Consequently, there is no use for any of the three Unix executable +bits that are present on a file in a Samba disk share. DOS files, +however, have their own attributes that need to be preserved when +they are stored in a Unix environment: the archive, system, and +hidden bits. Samba can preserve these bits by reusing the executable +permission bits of the file on the Unix side—if it is +instructed to do so. Mapping these bits, however, has an unfortunate +side effect: if a Windows user stores a file in a Samba share, and +you view it on Unix with the ls -al command, +some of the executable bits won't mean what +you'd expect them to.

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

After that, try creating a file in the share under Unix—such as +hello.java—and change the permissions of +the file to 755. With these Samba options set, you should be able to +check the permissions on the Windows side and see that each of the +three values has been checked in the Properties dialog box. What +about the read-only attribute? By default, Samba sets this whenever a +file does not have the Unix owner write permission bit set. In other +words, you can set this bit by changing the permissions of the file +to 555.

The default value of the map +archive option is yes, while +the other two options have a default value of no. +This is because many programs do not work properly if the archive bit +is not stored correctly for DOS and Windows files. The system and +hidden attributes, however, are not critical for a +program's operation and are left to the discretion +of the administrator.

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.

Figure 8-2. How Samba and Unix view the permissions of a file

Creation Masks

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

This is equivalent to a Unix umask of 113. If the user creates the +Wordpad document as before, it will show up as:

$ ls -l file.doc
+-rw-rw-r--    1 jay      jay             0 Sep 22 16:38 file.doc

Comparing this to the previous example, notice that not only has the +write permission for other disappeared as we expected, but so has the +execute permission for owner. This happened because the value of +create mask logically ANDs the +owner's permissions with a 6, which has masked off +the execute bit. The lesson here is that if you want to enable any of +map archive, +map system, or +map hidden, you must be careful +not to mask off the corresponding execute bit with your +create mask.

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

Also, you can force various bits with the force +create mode and +force directory +mode options. These options will perform a logical +OR against the file and directory creation masks, ensuring that those +bits that are specified will always be set. You would typically set +these options globally to ensure that group and world read/write +permissions have been set appropriately for new files or directories +in each share.

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

These options assign the same Unix username and group to every client +that connects to the share. However, this occurs +after the client authenticates; it does not +allow free access to a share. These options are frequently used for +their side effects of assigning a specific user and group to each new +file or directory that is created in a share. Use these options with +discretion.

Finally, one of the capabilities of Unix that DOS lacks is the +ability to delete a read-only file from a writable directory. In +Unix, if a directory is writable, a read-only file in that directory +can still be removed. This could permit you to delete files in any of +your directories, even if the file was left by someone else.

DOS filesystems are not designed for multiple users, and so its +designers decided that read-only means "protected +against accidental change, including deletion," +rather than "protected against some other user on a +single-user machine." So the designers of DOS +prohibited removal of a read-only file. Even today, Windows +filesystems exhibit the same behavior.

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

File and Directory Permission Options

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

The +options for file and directory permissions are summarized in Table 8-2; each option is then described in detail.

+ +

Table 8-2. File and directory permission options

+ 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 +

create mask

The argument for this option is an octal number indicating which +permission flags can be set at file creation by a client in a share. +The default is 0744, which means that the Unix owner can at most +read, write, and optionally execute her own files, while members of +the user's group and others can only read or execute +them. If you need to change it for nonexecutable files, we recommend +0644, or rw-r--r--. Keep in mind that the execute +bits can be used by the server to map certain DOS file attributes, as +described earlier. If you're altering the create +mask, those bits have to be part of the create mask as well.

directory mask

The argument for this option is an octal number indicating which +permission flags can be set at directory creation by a client in a +share. The default is 0744, which allows everyone on the Unix side +to, at most, read and traverse the directories, but allows only you +to modify them. We recommend the mask 0750, removing access by +"the world."

force create mode

This option sets the permission bits that Samba will set when a file +permission change is made. It's often used to force +group permissions, as mentioned previously. It can also be used to +preset any of the DOS attributes we mentioned: archive (0100), system +(0010), or hidden (0001).

TIP
+
When saving +documents, many Windows applications rename their datafiles with a +.bak extension and create new ones. When the +files are in a Samba share, this changes their ownership and +permissions so that members of the same Unix group +can't edit them. Setting force +create mode = 0660 will keep the new file editable +by members of the group.
+

force directory mode

This option sets the permission bits that Samba will set when a +directory permission change is made or a directory is created. +It's often used to force group permissions, as +mentioned previously. This option defaults to 0000 and can be used +just like the force create +mode to add group or other permissions if needed.

force group

This option, sometimes called group, assigns a +static group ID that will be used on all connections to a share after +the client has successfully authenticated. This assigns a specific +group to each new file or directory created from an SMB client.

force user

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.

delete readonly

This option allows a user to delete a directory containing a +read-only file. By default, DOS and Windows will not allow such an +operation. You probably will want to leave this option turned off +unless a program (for example, an RCS program) needs this capability; +many Windows users would be appalled to find that +they'd accidentally deleted a file that they had set +as read-only.

map archive

The DOS archive bit is used to flag a file that has been changed +since it was last archived (e.g., backed up with the DOS archive +program). Setting the Samba option map +archive = +yes maps the DOS archive flag to the Unix +execute-by-owner (0100) bit. It's best to leave this +option on if your Windows users are doing their own backups or are +using programs that require the archive bit. Unix lacks the notion of +an archive bit entirely. Backup programs typically keep a file that +lists what files were backed up on what date, so comparing +file-modification dates serves the same purpose.

Setting this option to yes causes an occasional +surprise on Unix when a user notices that a datafile is marked as +executable, but rarely causes harm. If a user tries to run it, he +will normally get a string of error messages as the shell tries to +execute the first few lines as commands. The reverse is also +possible; an executable Unix program looks like it +hasn't been backed up recently on Windows. But +again, this is rare and usually harmless.

For map archive to work properly, the execute bit for owner must not +be masked off with the create +mask parameter.

map system

The DOS system attribute indicates files that are required by the +operating system and should not be deleted, renamed, or moved without +special effort. Set this option only if you need to store Windows +system files on the Unix fileserver. Executable Unix programs will +appear to be nonremovable, special Windows files when viewed from +Windows clients. This might prove mildly inconvenient if you want to +move or remove one. For most sites, however, this is fairly harmless.

For map archive to work properly, the execute bit for group must not +be masked off with the create +mask parameter.

map hidden

DOS uses the hidden attribute to indicate that a file should not +ordinarily be visible in directory listings. Unix +doesn't have such a facility; it's +up to individual programs (notably, the shell) to decide what to +display and what not to display. Normally, you won't +have any DOS files that need to be hidden, so the best thing to do is +to leave this option turned off.

Setting this option to yes causes the server to +map the hidden flag onto the executable-by-others bit (0001). This +feature can produce a rather startling effect. Any Unix program that +is executable by world seems to vanish when you look for it from a +Windows client. If this option is not set, however, and a Windows +user attempts to mark a file hidden on a Samba share, it will not +work—Samba has no place to store the hidden attribute!

For map archive to work properly, the execute bit for other must not +be masked off with the create +mask parameter.

inherit permissions

When the inherit +permissions option is set to +yes, the create +mask, directory +mask, force +create mode, and +force directory +mode are ignored. The normal behavior of setting +the permissions on newly created files is overridden such that the +new files and directories take on permissions from their parent +directory. New directories will have exactly the same permissions as +the parent, and new files will inherit the read and write bits from +the parent directory, while the execute bits are determined as usual +by the values of the map +archive, map +hidden, and map +system parameters.

By default, this option is set to no.