Access control is the selective restriction of access to a resource. Access controls take many different forms and the sections below describe which ones can be used in QNX Neutrino systems.
umask
You can use umask to remove permissions when a file is created and apply this behavior system-wide. For information, see umask() in the C Library Reference and umask in the Utilities Reference.
POSIX permissions
POSIX permissions are the mechanism by which access permissions can be set on a resource. For example, the owner of a file in POSIX can assign read, write, and execute permissions for themselves, groups, and others accessing the file. POSIX permissions work in conjunction with the process UID and GID values including supplementary GIDs (referred to as SGIDs or groups). POSIX permissions are always present in a QNX Neutrino system and are not optional.
You can view POSIX permissions in the output of the ls -l command on a directory. For example:
# ls -la / total 1797040 drwxrwxr-x 12 root root 4096 Jun 02 16:17 . drwxrwxr-x 12 root root 4096 Jun 02 16:17 .. drwx------ 2 root root 4096 Jun 02 16:17 .boot drwxrwxr-x 2 root root 4096 Jun 02 16:17 bin dr-xr-xr-x 2 root root 0 Jun 02 17:11 dev drwxr-xr-x 5 root root 4096 Jun 02 17:00 etc drwxr-xr-x 3 root root 4096 Jun 02 16:17 home drwxr-xr-x 3 root root 4096 Jun 02 16:17 lib dr-xr-xr-x 2 root root 920035328 Jun 02 17:11 proc drwx------ 2 root root 4096 Jun 02 16:17 root drwxrwxr-x 2 root root 4096 Jun 02 16:17 sbin drwxrwxrwx 2 root root 4096 Jun 02 16:17 tmp drwxr-xr-x 7 root root 4096 Jun 02 16:17 usr drwxr-xr-x 5 root root 4096 Jun 02 16:17 var
The diagram below explains some of the fields related to POSIX permissions in the output above (mainly columns 1, 3, and 4).
For more information, see “File ownership and permissions” in the User's Guide
Access control lists (ACLs)
Access control lists (ACLs) are a form of finer grained and supplementary access control that can be granted on files, directories and other ephemeral system objects like resource manager paths. They can also serve as a way to dynamically apply POSIX permissions based on system settings and control decisions (like granting third-party services and applications access to system resources). This is controlled at runtime using the setfacl utility or programmatically with acl_set_file() or acl_set_fd(). For example:
# ls -l ntp.conf -rw-r--r-- 1 root root 0 Feb 06 15:14 ntp.conf # setfacl -m user:99:rw- ntp.conf # ls -l total 0 -rw-rw-r--+ 1 root root 0 Feb 06 15:14 ntp.conf
Note that this output has added the Extra bit (‘+’) on the end of the permissions to indicate that there is additional access control information. The Extra bit is a single character that specifies whether an alternate access method applies to the file. When this character is a space, there is no alternate access method. To inspect the information, use getfacl. For example:
# getfacl ntp.conf # file: ntp.conf # owner: root # group: root user::rw- user:99:rw- group::r-- mask::rw- other::r--
Only root or the owner of a file can change its ACLs. (For information on setting ACLs for resources, see acl_set_file() in the C Library Reference or setfacl in the Utilities Reference.
ACL support is usually ephemeral; that is, ACLs have to be re-applied to the various resources where they are used when the system reboots. Currently, only the Power-Safe Filesystem allows the pre-creation of ACLs at filesystem build time on the host. The Power-safe Filesystem is also the only filesystem that persists ACLs on disk. Some filesystems that QNX Neutrino supports have no ACL support.
Setuid and setgid programs
Executables can have the setuid or setgid permission bits set to have them run with the user ID or group ID of the executable’s owner or group. These bits can be a convenient way to allow a process to execute something that requires additional privilege. Setting these bits may also introduce security problems, particularly where an executable is setuid root. To improve security:-
Do not make a program setuid unless it was explicitly designed to be run this way.
-
Consider using pathtrust to prevent setuid programs being run from untrusted file systems. See “Pathtrust”.