Samba Administration Guide - Protecting Directories and Files from Deletion

The network administrator is strongly advised to read basic UNIX training manuals and reference materials regarding file and directory permissions maintenance. Much can be achieved with the basic UNIX permissions without having to resort to more complex facilities like POSIX ACLs or extended attributes (EAs).

UNIX/Linux file and directory access permissions involves setting three primary sets of data and one control set. A UNIX file listing looks as follows:

The columns represent (from left to right) permissions, number of hard links to file, owner, group, size (bytes), access date, time of last modification, and file name.

Any bit flag may be unset. An unset bit flag is the equivalent of "cannot" and is represented as a “-” character (see ???)

Additional possibilities in the [type] field are c = character device, b = block device, p = pipe device, s = UNIX Domain Socket.

The letters rwxXst set permissions for the user, group, and others as read (r), write (w), execute (or access for directories) (x), execute only if the file is a directory or already has execute permission for some user (X), set user (SUID) or group ID (SGID) on execution (s), sticky (t).

When the sticky bit is set on a directory, files in that directory may be unlinked (deleted) or renamed only by root or their owner. Without the sticky bit, anyone able to write to the directory can delete or rename files. The sticky bit is commonly found on directories, such as /tmp, that are world-writable.

When the set user or group ID bit (s) is set on a directory, then all files created within it will be owned by the user and/or group whose `set user or group' bit is set. This can be helpful in setting up directories for which it is desired that all users who are in a group should be able to write to and read from a file, particularly when it is undesirable for that file to be exclusively owned by a user whose primary group is not the group that all such users belong to.

When a directory is set d-wx--x---, the owner can read and create (write) files in it, but because the (r) read flags are not set, files cannot be listed (seen) in the directory by anyone. The group can read files in the directory but cannot create new files. If files in the directory are set to be readable and writable for the group, then group members will be able to write to (or delete) them.

Protecting Directories and Files from Deletion

People have asked on the Samba mailing list how is it possible to protect files or directories from deletion by users. For example, Windows NT/2K/XP provides the capacity to set access controls on a directory into which people can write files but not delete them. It is possible to set an ACL on a Windows file that permits the file to be written to but not deleted. Such concepts are foreign to the UNIX operating system file space. Within the UNIX file system anyone who has the ability to create a file can write to it. Anyone who has write permission on the directory that contains a file and has write permission for it has the capability to delete it.

For the record, in the UNIX environment the ability to delete a file is controlled by the permissions on the directory that the file is in. In other words, a user can delete a file in a directory to which that user has write access, even if that user does not own the file.

Of necessity, Samba is subject to the file system semantics of the host operating system. Samba is therefore limited in the file system capabilities that can be made available through Windows ACLs, and therefore performs a "best fit" translation to POSIX ACLs. Some UNIX file systems do, however support, a feature known as extended attributes. Only the Windows concept of inheritance is implemented by Samba through the appropriate extended attribute.

The specific semantics of the extended attributes are not consistent across UNIX and UNIX-like systems such as Linux. For example, it is possible on some implementations of the extended attributes to set a flag that prevents the directory or file from being deleted. The extended attribute that may achieve this is called the immutible bit. Unfortunately, the implementation of the immutible flag is NOT consistent with published documentation. For example, the man page for the chattr on SUSE Linux 9.2 says:

A file with the i attribute cannot be modified: it cannot be deleted
or renamed, no link can be created to this file and no data can be
written to the file. Only the superuser or a process possessing the
CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

A simple test can be done to check if the immutible flag is supported on files in the file system of the Samba host server.

Procedure15.1.Test for File Immutibility Support

Create a file called filename.
Login as the root user, then set the immutibile flag on a test file as follows:
```
root#  chatter +i `filename'
```
Login as the user who owns the file (not root) and attempt to remove the file as follows:
```
mystic:/home/hannibal > rm filename
```
It will not be possible to delete the file if the immutible flag is correctly honored.

On operating systems and file system types that support the immutible bit, it is possible to create directories that cannot be deleted. Check the man page on your particular host system to determine whether or not immutable directories are writable. If they are not, then the entire directory and its contents will effectively be protected from writing (file creation also) and deletion.

File and Directory Access Control

Protecting Directories and Files from Deletion