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

[1] The system checkbox will probably be grayed for your file. Don't worry about that ”you should still be able to see when the box is checked and when it isn't.

Figure 8-1. DOS and Windows file properties
figs/sam2_0801.gif

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
figs/sam2_0802.gif

8.2.1 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 

8.2.2 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

8.2.2.1 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.

8.2.2.2 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."

8.2.2.3 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).

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.

8.2.2.4 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.

8.2.2.5 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.

8.2.2.6 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.

8.2.2.7 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.

8.2.2.8 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.

8.2.2.9 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.

8.2.2.10 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.

8.2.2.11 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 .

   


Using Samba
Using Samba: A File and Print Server for Linux, Unix & Mac OS X, 3rd Edition
ISBN: 0596007698
EAN: 2147483647
Year: 2003
Pages: 475

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net