File and Directory Access Control
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:
drwxr-xr-x 13 maryo gnomes 816 2003-05-12 22:56 .
drwxrwxr-x 37 maryo gnomes 3800 2003-05-12 22:29 ..
dr-xr-xr-x 2 maryo gnomes 48 2003-05-12 22:29 muchado02
drwxrwxrwx 2 maryo gnomes 48 2003-05-12 22:29 muchado03
drw-rw-rw- 2 maryo gnomes 48 2003-05-12 22:29 muchado04
d-w--w--w- 2 maryo gnomes 48 2003-05-12 22:29 muchado05
dr--r--r-- 2 maryo gnomes 48 2003-05-12 22:29 muchado06
drwsrwsrwx 2 maryo gnomes 48 2003-05-12 22:29 muchado08
---------- 1 maryo gnomes 1242 2003-05-12 22:31 mydata00.lst
--w--w--w- 1 maryo gnomes 7754 2003-05-12 22:33 mydata02.lst
-r--r--r-- 1 maryo gnomes 21017 2003-05-12 22:32 mydata04.lst
-rw-rw-rw- 1 maryo gnomes 41105 2003-05-12 22:32 mydata06.lst
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.
An overview of the permissions field is shown in
Overview of UNIX permissions
Figure15.1.Overview of UNIX permissions field.
Any bit flag may be unset. An unset bit flag is the equivalent of "cannot" and is represented
as a “-” character (see
^^^ The owner (user) can read, write, execute
^^^ the group can read and execute
^^^ everyone else cannot do anything with it.
Additional possibilities in the [type] field are c = character device, b = block device, p = pipe device,
s = UNIX Domain Socket.
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
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
Unfortunately, the implementation of the immutible flag is NOT consistent with published documentation. For example, the
man page for the
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
Procedure15.1.Test for File Immutibility Support
Create a file called
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.