File ownership and permissions

Each file and directory belongs to a specific user ID and group ID, and has a set of permissions (also referred to as modes) associated with it. You can use these utilities to control ownership and permissions:

To: Use:
Specify the permissions for a file or directory chmod
Change the owner (and optionally the group) for a file or directory chown
Change the group for a file or directory chgrp

For details, see Utilities.

You can change the permissions and ownership for a file or directory only if you're its owner or you're logged in as root. If you want to change both the permissions and the ownership, change the permissions first. Once you've assigned the ownership to another user, you can't change the permissions.

Permissions are divided into these categories:

u
Permissions for the user (that is, the owner).
g
Permissions for the group.
o
Permissions for others (that is, everyone who isn't in the group).

Each set of permissions includes:

r
Read permission.
w
Write permission.
x
Execute permission. For a directory, this is permission to list or search the directory.
s or S
Setuid or setgid.
t or T
Sticky bit.

For example, if you list your home directory (using ls -al), you might get output like this:

total 94286
drwxr-xr-x 18 barney    techies        6144 Sep 26 06:37 ./
drwxrwxr-x  3 root      root           2048 Jul 15 07:09 ../
drwx------  2 barney    techies        4096 Jul 04 11:17 .AbiSuite/
-rw-rw-r--  1 barney    techies         185 Oct 27  2000 .Sig
-rw-------  1 barney    techies          34 Jul 05  2002 .cvspass
drwxr-xr-x  2 barney    techies        2048 Feb 26  2003 .ica/
-rw-rw-r--  1 barney    techies         320 Nov 11  2002 .kshrc
-rw-rw-r--  1 barney    techies           0 Oct 02 11:17 .lastlogin
drwxrwxr-x  3 barney    techies        2048 Oct 17  2002 .mozilla/
drwxrwxr-x 11 barney    techies        2048 Sep 08 09:08 .ph/
-rw-r--r--  1 barney    techies         254 Nov 11  2002 .profile
drwxrwxr-x  2 barney    techies        4096 Jul 04 09:06 .ws/
-rw-rw-r--  1 barney    techies        3585 Dec 05  2002 123.html

The first column is the set of permissions. A leading d indicates that the item is a directory; see Types of files.

If the permissions are followed by a plus sign (+), the file or directory has an access control list that further specifies the permissions. For more information, see Access Control Lists (ACLs).

You can also use octal numbers to indicate the modes; see chmod in Utilities.

Setuid and setgid

Some programs, such as passwd, need to run as a specific user to work properly:

$ which -l passwd
-rwsrwxr-x  1 root      root         21544 Mar 30 23:34 /usr/bin/passwd

Notice that the third character in the owner's permissions is s. This indicates a setuid (set user ID) command; when you run passwd, the program runs as the owner of the file (that is, root). An S means that the setuid bit is set for the file, but the execute bit isn't set.

You might also find some setgid (set group ID) commands, which run with the same group ID as the owner of the file, but not with the owner's user ID. If setgid is set on a directory, files created in the directory have the directory's group ID, not that of the file's creator. This scheme is commonly used for spool areas, such as /usr/spool/mail, which is setgid and owned by the mail group, so that programs running as the mail group can update things there, but the files still belong to their normal owners.

If you change the ownership of a setuid command, the setuid bit is cleared, unless you're logged in as root. Similarly, if you change the group of a setgid command, the setgid bit is cleared, unless you're root.

Setuid and setgid commands can cause a security problem. If you create any, make sure that only the owner can write them, and that a malicious user can't hijack them—especially if root owns them.

Sticky bit

The sticky bit is an access permission that affects the handling of executable files and directories.

  • If it's set for an executable file, the kernel keeps the executable in memory for a while after the program ends—the exact length of time depends on what else is happening in the system. This can improve the performance if you run a program (for example, a compiler or linker) frequently.
  • For a directory, it affects who can delete a file in the directory. You always need to have write permission on the directory, but if the sticky bit is set for the directory, you also need to be the owner of the file or directory or have write permission on the file.

If the third character in a set of permissions is t (for example, r-t), the sticky bit and execute permission are both set; T indicates that only the sticky bit is set.

Default file permissions

Use the umask command to specify the mask for setting the permissions on new files. The default mask is 002, so any new files give read and write permission to the user (that is, the owner of the file) and the rest of the user's group, and read permission to other users. If you want to remove read and write permissions from the other users, add this command to your .profile:

umask 006

Access Control Lists (ACLs)

Some file systems, such as the Power-Safe (fs-qnx6.so) file system, extend file permissions with Access Control Lists, which are based on the withdrawn IEEE POSIX 1003.1e and 1003.2c draft standards. With the traditional file permissions as set with chmod , if you want someone to have special access to a file, you have few choices:

  • Adding that person to the owning group
  • Creating a supplemental group that includes that person and the owner of the file
  • Loosening the permissions for others

Keeping track of the users in each group and can become complicated, and allowing others additional permissions can make your system less secure. ACLs extend file permissions, giving you finer control over who has access to what. In an ACL, the permissions are divided into these classes:

  • Owner class
  • Group class, consisting of named users, the owning group, and named groups
  • Others (or world) class

An access control list consists of a number of entries, each in one of the following forms (given with the constants used in code to identify the tag type):

Entry type Tag type Form
Owner ACL_USER_OBJ user:: permissions
Named user (identified by name or by numerical ID) ACL_USER user: user_identifier : permissions
Owning group ACL_GROUP_OBJ group:: permissions
Named group (identified by name or numerical ID) ACL_GROUP group: group_identifier : permissions
The upper bound on permissions for the group class ACL_MASK mask:: permissions
Others ACL_OTHER other:: permissions

The permissions are in the form rwx, with a hyphen (-) replacing any permissions that aren't granted. Here's an example of the ACL for a file:

user::rw-
user:violetta:r--
group::rw-
mask::rw-
other::---

The owner of the file has read and write permissions, as does the owning group. Others have no permissions at all. The user violetta has been granted read permission, so she's more privileged than others, but not quite as privileged as the owning user or group. If violetta hadn't been granted a special permission, the ACL would be the same as file permissions of rw-rw----.

If an ACL can be represented simply as file permissions, it's called a minimal ACL; if it can't, it's called an extended ACL. An extended ACL always has a mask entry, and can include any number of entries for named users and named groups. If a file or directory has an extended ACL, its permissions in the output of ls -l are followed by a plus sign (+).

The mask entry is the union of the permissions for the owning group, all named users, and all named groups. For example, let's consider a file whose owning group has no write permission:

# ls -l file.txt
-rw-r--r--   1 mabel    techies          50 Sep 27 21:22 file.txt

If we use the getfacl utility to get its ACL, we see:

# getfacl -q file.txt
user::rw-
group::r--
other::r--

The -q option suppresses some comments, listing the file name, owner, and group, that getfacl displays by default. Next, let's suppose that mabel uses setfacl to add an entry for frank that grants him read and write permission (to modify the ACL, you must be the owner of the file or directory, or have appropriate privileges):

# setfacl -m u:frank:rw- file.txt
# getfacl -q file.txt
user::rw-
user:frank:rw-
group::r--
mask::rw-
other::r--
# ls -l file.txt
-rw-rw-r--+  1 mabel    techies          50 Sep 27 21:22 file.txt

In addition to the entry for frank, the ACL now includes a mask entry that lists read and write permission. The output of ls also indicates read and write permission for the group.

Modifying the file permissions (for example, using chmod) can affect the ACLs, and vice versa:

  • The user file permissions and the permissions in the owning user ACL entry always match.
  • The other file permissions and the permissions in the other ACL entry always match.
  • If the ACL doesn't have a mask entry, the group file permissions and the permissions in the owning group ACL entry match.
  • If the ACL has a mask entry, its permissions match the group file permissions. In this case, the owning group ACL entry's permissions aren't necessarily the same as the group file permissions.

Let's continue with the same sample file. Now, let's have mabel use chmod to remove write permission for the group:

# chmod g-w file.txt
# getfacl -q file.txt
user::rw-
user:frank:rw-          # effective: r--
group::r--
mask::r--
other::r--
# ls -l file.txt
-rw-r--r--+  1 mabel    techies          50 Sep 27 21:22 file.txt

The entry for frank still lists read and write permission, but a comment warns us that his effective permissions are read only, because we explicitly removed write permission from the mask.

The following pseudo-code shows the algorithm for checking the access to a file or directory:

if (the process's effective user ID matches the object owner's user ID)
{
   The matched entry is the owner ACL entry
}
else if (the process's effective user ID matches the user ID specified in any
         named user ACL entry)
{
   The matched entry is the matching named user entry
}
else if (the process's effective group ID or any of its supplementary group IDs
         matches the group ID of the object or matches the group ID
         specified in any named group entry)
{
   if (the requested access modes are granted by at least one entry
       matched by the process's effective group ID or any of its supplementary
       group IDs)
   {
       The matched entry is one of the granting entries (it doesn't matter which)
   }
   else
   {
       Access is denied
   }
}
else if (the requested access modes are granted by the other ACL entry)
{
   The matched entry is the other entry
}

if (the requested access modes are granted by the matched entry)
{
   if (the matched entry is the owning user or other entry)
   {
       Access is granted
   }
   else if (the requested access modes are also granted by the mask entry,
            or no mask entry exists in the ACL)
   {
       Access is granted
   }
   else
   {
       Access is denied
   }
}
else
{
    Access is denied
}

For more information about getfacl or setfacl , see Utilities.

There are also functions that you can use to work with ACLs in your programs; for information about them, see Working with Access Control Lists in the BlackBerry 10 OS programmer's guide, and the acl_*() entries in the BlackBerry 10 OS C Library.

  • The POSIX draft also describes default ACLs that specify the initial ACL for new objects created within a directory. Default ACLs aren't currently implemented.
  • ACLs are currently ephemeral; if you reboot your system, any ACLs are lost.
  • Changes to file permissions resulting from a change to an ACL do persist across reboots.
  • The cp utility doesn't copy any ACL that the source file has, but if the destination file already exists and has an ACL, its ACL is preserved.

Last modified: 2014-11-17



Got questions about leaving a comment? Get answers from our Disqus FAQ.

comments powered by Disqus