"Linux" Linux Rights Management and special permissions

Linux Rights Management

Rights Management This aspect, very clearly remember the beginning of the internship was carefully studied, do not know why there is no note left mark. In addition to some basic knowledge point has long been forgotten, helpless had to start from scratch to learn again.

Knowledge of basic permissions

This part is a relatively basic, do not want to talk more. is mainly the understanding of the 9-lattice permission. Find out what the read, write, and execute permissions are for files and directories. Here are some of the points that have not been paid much attention to after listening to the training today and feel some meaning:

Permissions to manage permissions

File permission information, like other file information, is not part of the content of the file, and the basic permissions are for the content of the file. For example:

-rwxrwxrwx  1 zabbix Zabbix      0 August  : file1

This file1 belongs to Zabbix, and its permissions are the most open 777, another non-root user such as User1 can read, modify, execute this file, but User1 still do not have permission to file1 and other operations. In general, users who have Chmod,chown permissions on a file or directory have only root and the owner of that file/directory. So in Linux, there should be a permission mechanism to manage permissions, but this mechanism does not open the interface for users to modify the use of it.

Permissions for multi-level directories by nearest principle

For a multi-tiered directory, there may be a situation where the user is privileged for the directory One,three and file files, and the user does not have permission to execute (even if he has read and write permissions) for both directories, One/two/three/file Level_ Three and file information and content cannot even be created to delete files from the Level_three directory's siblings in the Level_two directory. Because the system by default, if you want to read or modify the contents of the directory, you must first enter the directory, which I feel is not the same. Because the need to enter the directory, nature requires x permission, otherwise everything is flying blind white talk.

One point you can point out is that this example, if the user in one directory will be in the first directory in the contents of the content, you can see a scene:

As you can see, the three directory and the file testfile of the three sibling (again, not the specific permissions of the two) are displayed, but the information that is not sufficient and shows the two is limited (name only). It's impossible to see what's inside of three.

The UID in passwd represents who the user is.

This should also be mentioned in the article which the user manages. The core thing is, Linux, most users recognize the job is to rely on the UID this number, not the user name. So if we change the UID of one of the users in passwd to 0 (root uid), then he becomes the root user and can do things directly in many places by root.

Use of the Chage command

It is well known that passwd can be used to modify its own password, and if it is root, it can also be used to modify the password of all users. However, many of the configuration options for this password are the default options. If you need to further refine the password configuration, you will use the Chage command. Elsewhere, it might have been said that the Chage command was based on/etc/shadow. The information obtained through chage and the chage to be modified are basically the shadow file. The description of the shadow file is written in the user management chapter, and the basic use of chage is as follows:

$chage [-LDEIMMW] <username> parameters:-l    List all password configurations for this account -d    Date Modify the third field of the shadow (the date the password was last changed)-E    Date  Modify the eighth field of the shadow (account expiration date)-I    receive the number of days  Modify the seventh field of the shadow (password expiration date)-m    number   of days modify the fourth field of shadow (minimum password retention days)-m    number of days    Modify the fifth field of the shadow (the password needs to be modified after how long)-W +    days    Modify the sixth field of Shadow (before password expiration warning date)

A bit more in-depth knowledge of permissions

Basic rights knowledge in 80% of the situation is sufficient, and then the authority to control the need for more complex rights management tools. Here are some of the rights management aspects that Linux can often hear and occasionally use.

Umask Default Permissions

When a user creates a default file/directory, it automatically assigns permissions to the file/directory. This default value is controlled by the umask. By default the Umask is 0022, and the first bit 0 is reserved for special permissions Suid,sbit These, regardless of the first. The latter three bits correspond to Owner,group and others respectively.

It is important to note that the umask datum values for the new file and the new directory are not the same. for a user-created file, the baseline value is 666, so a new file created under the 022 umask default permission is 644. The baseline value is 777 when the user creates a new directory, so the default permissions for the new directory under 022umask are 755.

Chattr,lsattr

　　Note that these two commands are only valid on some file systems. It is said that Chattr does not work in directories such as/,/var,/dev.

Files can be managed by chattr and lsattr to hide permission properties. The so-called hidden attribute, that is, by default, all new files and directories do not have, users need to refine their own set of rights management tools. The previous training also did not mention this piece of content, but I see the discovery is still very useful!

First look at the lsattr. Lsattr < file name > You can view all hidden permissions for a file/directory, and if the file name parameter is not present, the hidden attribute information for all files/directories in the current directory is given. Because the hidden permissions are all empty by default, we usually see Yimapingchuan:

[Email protected] tmp]#lsattr---------------- ./test.py---------------- ./Demofile---------------- ./Uwsgiconfig.ini----------------./libcurl-devel-7.29.0- *. el7.centos.i686.rpm----------------./libcurl-devel-7.29.0- *. el7.centos.x86_64.rpm----------------./systemd-private-ca6e7179ff254d749f6efc37e1a66006-httpd.service-GSL2NW---------------- ./test.c---------------- ./file1---------------- ./Level_one----------------./test

Let's look at the usage of chattr:

chattr [+-=] [Asacdistu] < filename or directory name >+,- followed by a letter parameter, indicating that a hidden property is added or subtracted for the target file
-R can recursively set the hidden properties of all files in the directory, so be sure to write them in front of the "+-Properties". A: After setting the A property, access to the file does not modify the access time Atime, for files that require frequent I/O, plus this property can improve the IO efficiency s: The general Write file is asynchronous (after caching), if you add this hidden attribute then the write disk operation is synchronous a: Once a has been set, this file will only add data and cannot modify or reduce the data. Only the root user can set this property C: The file with the C property is automatically compressed, stored on disk in a compressed state, and extracted automatically when read. For memory adequacy but disk catch-up situation applies D: Set the D property of the file is not backed up by the dump program I: Set the I attribute of the file will not be deleted (even if the root user delete), and can not modify its contents, in the security of important files to make a great contribution to, Only the root user can set this property u: the file with the U property set is deleted and not erased from the hard disk, but can be retrieved by some means (I do not know what means). )

Where the genus I attribute and a attribute are useful, especially to ensure the security of the system. Because it is a hidden property, it has great concealment, so it sometimes causes unexpected problems. For example, when you suddenly encounter a file that cannot be deleted anyway. You can think of the problem of whether the property is hidden. This also from the reverse side, in the setting of the hidden properties must be cautious & leave marks, do not whim of a set, after thinking can not remember.

Suid,sgid and Sbit

This aspect is briefly explained in the messy notes. Now let's make it clear.

SUID

SUID, shown as s on the file owner's execution permission bit. SUID permissions are only valid for binary files (judging if binary files can be viewed through file <filename>, as I thought before.) py,.sh what it is. Plus the X permission is the binary file is not right. Something like the one compiled with GCC is the real binary file.

The specific meaning of the S permission is that when the owner of a file executes the permission bit is S, the other user executes the binary, and during execution, the user obtains the permissions of the file owner. It is important to note that the user who executes the program has an X permission on the program itself. If the permissions of a file belonging to Root:root are-RWS------, then the general user is not authorized to do so. Must be changed to-RWS-----x.

Using the SUID scenario, the classic "read and write files are restricted". For example, I have a file that belongs to root, and I want other users to read and write to it under certain limits. Obviously can't open RW to them. So I can do this, set this file to only root readable writable, then write a binary program (the program owner is root), in the program to make read and write control, and then the program's owner execution bit set to S. In this way, other users can read and write to the file through this program, so that "limited read and write" is done. This approach is somewhat analogous to private variables in object-oriented programming. Variables are not allowed to be changed directly, but the Setvar method is set aside as an interface to change the value of the variable. In fact, the mechanism for users to change passwords in Linux is achieved through SUID. General users can execute/usr/bin/passwd to change their password, but the password information is placed in the/etc/shadow inside, this file only the root readable can be forced to write. Ordinary users change the password, that is, modify the file can not be directly modified, can only be done by/usr/bin/passwd this binary file, so/usr/bin/passwd is a file with suid permissions.

Adding SUID permissions can be done by chmod 4xxx < file name >. You can see that the fourth bit of the permission code appears. You can also add suid permissions by using the chmod u+s < file name > method.

SGID

Sgid permissions and suid are similar, but instead of "Execute with File owner permissions" to "Execute the permissions of the members of all groups in the file." That is to say Sgid is similar to-rwxr-sr-x this place has a s permission.

Another sgid has a big difference in that it can be applied to the directory. The effect of the directory is that the user must have read and execute permissions to the directory, so that he can be able to enter the directory, and then the user all the actions in this directory, the effective user group is the user group of the directory, and again, if the user has W permissions to the directory, The user group for all new files created by the user is the same as the user group for this directory.

Sbit

Sbit permissions only valid for the directory, set the Sbit directory effect is: The precondition is still the same, the user needs to have W and x permissions on the directory, that is, the user has to create new and delete files in this directory permissions, and then the special place is that users in this directory can only delete their own created files and directories, It cannot be deleted for others to create. The Sbit permission is represented by T on the 11th bit of the 10-bit permission character. For example, this is the directory with Sbit permissions: Drwxrwxrwxt.

The above three special permissions also have a special encoding method, Suid is 4,sgid is 2,sbit is 1. Put special permissions on the first bit of the permission, you can get the full permission character, such as chmod 4711 will change the permissions to-rws--x--x.

Finer-grained permission planning

All of the above rights management is based on the user and user groups, and the file can only be moved, can not do different files between the refinement of permissions. For example, most of the files are suitable for group1 in the User1,user2,user3 of the three users, but a new file requirements even in the group1 subdivision, so that User1,user2 readable, user3 unreadable, then need more granular rights management tools. This tool is an ACL.

The first point to note is that the ACL needs to indicate that the file system should join ACL support when mounting the file system.

Like Chattr,lsattr, ACLs have Getfacl and Setfacl to get and set ACL permissions. The following is a detailed look at the usage of the two commands:

#setfacl [-BKRD] [{-m|-x} ACL parameter]  < filename >-m    file-related ACL parameter, cannot be set with-x to    delete file-related ACL parameters, cannot be associated with- m same -b    Delete all ACL parameters -k    Delete default ACL parameter -R    recursion set ACL parameter -D    Set the default ACL parameters for a directory, and all newly created subdirectories (excluding files) under the directory will apply this parameter

As mentioned above, ACLs are fine-tuned for each user, so it is also necessary to indicate the user or user group that is targeted when using the command. Generally speaking, this command can be used in the following ways:

Setfacl-m U:user1:rx File The meaning of this command is that it is r-x to set User1 permissions for the user. After the setup is successful, the permissions interface given in the LL file will have a "+" in the last one of the permission characters, such as-rwxr-xr-x+. If you start with u in an ACL parameter (for a single user) and then do not write a user name, such as U::RWX, it is set by default for the file owner. Of course, if the permission is set for the file owner through the ACL, the file may end up not showing the + sign, because the file owner's permission information and management can be shown by the traditional 9-grid permission, which can be changed. In addition to individual users, you can set ACL permissions on a user group. The usage is simply to change the u:xx:xx in ACL permissions to G:xx:xx. In addition, in addition to the beginning of the two ACL parameters of the U and G, there is an ACL parameter that begins with M. M is the meaning of mask, and the usage is similar to m:rwx, the middle does not need to take any specific user or user group, it means to set a ceiling for the ACL permission of a file, the permission beyond the portion of this ceiling will not be recognized. For example, after a file has been m:r set, and then set U:USER:RWX, although you can set the success, but the user still only read access to the file (of course, if you are the root user, you can force the writing is another matter)

For these files with the + sign in the permission information, we can use Getfacl <filename> to get its ACL detailed permissions. For set permissions and mask conflicts, the system also gives a conflicting hint telling you what the actual permissions are.

"Linux" Linux Rights Management and special permissions