tencent cloud

TencentOS Server

문서TencentOS ServerUser GuideSecurity ConfigurationFile Permissions and ACLs

File Permissions and ACLs

다운로드
포커스 모드
폰트 크기
마지막 업데이트 시간: 2026-10-19 17:22:49
AI 번역
This document describes file permission management in TencentOS Server, including SUID/SGID/Sticky BIT special permissions, umask settings, and ACL (access control list) configuration methods.

Properly Configuring File Permissions

In Linux, both regular files and directories can be treated as files, and file security is primarily controlled through permissions and ownership. In a file system, file access is generally controlled through the common rwx permissions. However, in some scenarios, the single rwx permission may not be flexible enough, and the special permission s is also used. For example, the /etc/shadow file stores the encrypted passwords of all users in the system, so access to this file cannot be directly granted to all users. However, ordinary users do need to change their passwords, so the SUID permission can be introduced to allow users to change their own passwords.

SUID Permission

View SUID permissions
When an ordinary user changes their password, the permission to operate the /etc/shadow file is not directly granted. Instead, the operation is performed through /usr/bin/passwd, so the SetUID (SUID) permission must be granted first. You can use ls to check:
ls -l /usr/bin/passwd
Output example:
-rwsr-xr-x. 1 root root 31984 Mar 31 23:51 /usr/bin/passwd
You can see that the owner permission is rws instead of rwx. When s appears in the position of x, it is called SetUID Bits or SUID. Its characteristics are as follows:
The SUID permission applies only to executable binary files.
When an executor has execute permission on the binary file, the executor temporarily gains the owner permission of the file.
Therefore, during this password modification process, when ordinary users run the /usr/bin/passwd command, they temporarily gain root permissions to run the command and complete the password modification.
Set SUID permissions
SUID permissions can be set using symbolic notation or numeric notation. The SUID permission corresponds to the number 4:
chmod u+s filename  # Symbolic notation, where + indicates adding the permission
chmod 4755 filename  # Numeric notation, corresponding to the number 4
Remove SUID permissions
SUID permissions can be removed using either symbolic or numeric notation:
chmod u-s filename  # Symbolic notation, where - indicates removing the permission
chmod 755 filename  # Numeric notation

SGID Permission

View SGID permissions
SGID applies to directories, and user groups also have an equivalent attribute: SGID. Its characteristics are as follows:
The SGID permission applies to directories.
New files created by users in this directory will have the same user group as the directory.
You can view the SGID permission of a directory by using the ls -ld command. In the following example, the directory /shared/project has been assigned the SGID permission through chmod 2755:
ls -ld /shared/project
Output example:
drwxr-sr-x. 2 root root 4096 May 6 15:03 /shared/project
In the output, the user group permission bits are r-s, where s appears in the position of the user group execute permission x, indicating that the directory has been assigned the SGID permission.
SGID permission settings
SGID permissions can be set using symbolic or numeric notation. The SGID permission corresponds to the number 2:
chmod g+s dirname  # Symbolic notation, where + indicates adding the permission
chmod 2755 dirname  # Numeric notation, corresponding to the number 2
Removing SGID permissions
chmod g-s dirname  # Symbolic notation, where - indicates removing the permission
chmod 755 dirname  # Numeric notation

Sticky BIT Permission

View SBIT permissions
Sticky BIT (fully known as the restricted deletion flag or sticky bit, abbreviated as SBIT) can be understood as the sticky bit or deletion-prevention bit.
SBIT is currently only effective on directories, where it prevents non-owners from deleting files. A common example is the /tmp directory:
ls -ld /tmp/
Output example:
drwxrwxrwt. 7 root root 140 May 6 15:03 /tmp/
It can be seen that the last bit in the permission information is set to t, indicating that the SBIT permission is set for this directory. At this point, when users create a file or directory under this directory, only themselves and root users have permission to delete it, preventing others from deleting it.
SBIT permission settings
SBIT can also be set using symbolic or numeric notation, with the numeric notation corresponding to 1:
chmod o+t dirname  # Symbolic notation, where + indicates adding the permission
chmod 1755 dirname  # Numeric notation, corresponding to the number 1
Remove SBIT permission
chmod o-t dirname  # Symbolic notation, where - indicates removing the permission
chmod 755 dirname  # Numeric notation

Setting the Value of umask

The user file-creation mode mask (umask) value is used to set default permissions for newly created files and directories. If no umask value is set, the generated files are writable by any system user, which poses a certain risk.
You can run umask to view the default umask value of the current system:
umask
Output example:
0022
Note:
The default umask value for root users is 0022, and that for ordinary users is 0002. The default permissions for newly generated directories/files are 777/666 minus the umask value.
You can also specify a stricter umask value based on your actual security needs:
Temporary change:
umask 0037  # Takes effect temporarily
Permanent change:
To persistently change the umask value in the system, you can edit /etc/bashrc to modify the existing umask line, or add a umask setting at the end of the file (effective for all users). For example, to change the umask value to 0037, add the following line at the end of /etc/bashrc:
umask 0037
If you only need to persistently change the umask value for a single user, you can also add the same setting at the end of that user's ~/.bashrc file. After the modification is complete, log in again or run the following command to make the configuration take effect immediately:
source /etc/bashrc
Note: Changes to /etc/profile are only executed when a user logs in for the first time, while changes to /etc/bashrc are executed every time a user logs in and loads the shell.

Configuring the ACL

In Linux systems, Access Control List (ACL) serves as an important security mechanism. Traditional file permissions assign different rwx permissions to owner/group/others for each file and directory. Building upon this, ACL adds a set of finer-grained access control rules to each file and directory, allowing you to configure different access permissions for different users and groups.

Installing the ACL

ACL is now supported as a built-in feature, so manual installation is not required in most cases. If it is not pre-installed under special circumstances, you can install the ACL manually:
sudo dnf install acl

Viewing the ACL

To view the ACL of a file or directory, you can use the getfacl command. For example, to view the ACL settings of file1:
getfacl file1
The command will display ACL of the corresponding file, including default permissions, access permissions for the owner and the group to which the file belongs, as well as any access permissions for specific users or groups. For example:
# file: file1
# owner: root
# group: root
user::rw-
group::r--
other::r--

Setting the ACL

To set the ACL of a file or directory, you can use the setfacl command. For example, to grant the user opencloudos read, write, and execute permissions on file1:
sudo setfacl -m u:opencloudos:rwx file1
Then view the ACL of file1 again:
getfacl file1
Output example:
# file: file1
# owner: root
# group: root
user::rw-
user:opencloudos:rwx
group::r--
mask::rwx
other::r--
You can see that the user:opencloudos:rwx line has been added, indicating that the user opencloudos has read, write, and execute permissions on file1. Meanwhile, ACL automatically generates a mask entry, which represents the maximum effective permissions for all users and groups in the ACL.

Setting the Group ACL

You can set ACLs for user groups. For example, to grant read and write permissions to the devteam group:
sudo setfacl -m g:devteam:rw file1

Deleting an ACL Entry

Delete the ACL entry for a specific user or group:
sudo setfacl -x u:opencloudos file1
Delete all extended ACL entries to restore basic permissions:
sudo setfacl -b file1

Setting the Default ACL

You can set a default ACL for a directory so that new files and subdirectories created in that directory automatically inherit the ACL rules:
sudo setfacl -d -m u:opencloudos:rx /shared/project
In this way, for files newly created in the /shared/project directory, the user opencloudos will automatically obtain read and execute permissions.

Recursively Setting the ACL

Set ACLs recursively for a directory and its subdirectories and files:
sudo setfacl -R -m u:opencloudos:rwx /shared/project
Warning:
Use caution when setting ACLs recursively to avoid granting excessive permissions.
이전 주제: Authentication and Services (PAM-Kerberos-SSSD)다음 주제: Encryption and Signature

도움말 및 지원

문제 해결에 도움이 되었나요?

피드백

키워드로 검색
    Enter keywords to search documentation