[8-30] Special permissions on Linux file systems (SUID, SGID, Sticky)

Knowledge Reserve

• Permission model

  • • For a file, Linux defines 3 different permissions for 3 types of objects;

    • Class 3 objects: Master U, Group G, Other O

    • 3 Permissions: Read permission r, write permission W, execute permission X

• A directory has a.txt this file, the user can delete this file depends on whether the user has write permission to a directory, and not to A.txt have write permission, remember!

• < Span style= "line-height:0px;" >

  • • Each process also has the owner, the group, the process needs to access the file also has the owner, the genus Group

    • By default, the owner of the process is the process initiator, the user

    • The group of processes is the basic group of this user

• In fact, in addition to the RWX3 class permissions, Linux also has a special permission model SUID, SGID, STICKY
  

The security context of the process

• Can any user start a executable program file as a process?

  • • Depends on whether the user has execute [x] permissions on the file

• After the program is started as a process, the owner of the process is the user, and the group defaults to the base group where the user resides, that is, the initiator decides

• Process may have access to modify other files, then the process's access rights depend on the owner's access rights

  • • The owner of the process, and the owner of the file, the application file is the owner of the Authority;

    • The owner of the process, the same file belongs to the group, the application of the file belongs to the group of permissions;

    • Otherwise, the permissions of the other user are applied.

SUID

Let's take a look at a password change example

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M01/72/B5/wKiom1XryhGgEg3cAAosaCEZDHo022.bmp "title=" 2222. BMP "alt=" Wkiom1xryhggeg3caaosacezdho022.bmp "/>

After changing the password will eventually be stored in the/etc/shadow file, although the user has the passwd command execution permissions, then user A in the execution of the passwd process, the owner of the process is a group is a, and the shadow file has a permission of 000, referring to the security context of the process described above , there is no permission to change the password, then why can we change the password success?

Look at the passwd this executable program file permissions, whether it is different from the usual file?

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M00/72/B1/wKioL1XrzRCwkF07AAC9m82t5Ak307.jpg "title=" Baidushurufa_2015-9-6_13-10-54.png "alt=" wkiol1xrzrcwkf07aac9m82t5ak307.jpg "/> unexpectedly is RWS, unexpectedly appeared the S permission?"

The so-called S permission is actually the suid of 3 kinds of special permission;

• Any user to execute this program, the owner of the resulting process is no longer the initiator, but the executable program file itself is the owner of the initiator, has a high authority, this is the suid mechanism. Here a user executes passwd actually the process owner is no longer a but root so can change the password, you know;

• Any executable program file can be started as a process, depending on whether the initiator has X permission on the program file;

• when initiated as a process, its owner is no longer the initiator, but the program file's own owner; SU ID

• How do I set suid permissions?

  • • Chmod u+s File ....

    • Chmod u-s File ....

    • Please note , S and S may appear on the privilege bit, and their meaning is actually different

      • S: Owner has x permission

      • S: Owner has no x permission

SGID

By default, user A creates a file whose owner is a, which is a basic group of a, which is fine. If in a common directory, people create their own files want to work together, but because of this default mechanism of the system obviously a user access B user's files will be banned, because not a group Ah!

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M01/72/B1/wKioL1Xr0Hmy_tQuAAHgjDVqC30482.jpg "title=" Baidushurufa_2015-9-6_13-25-30.png "alt=" Wkiol1xr0hmy_tquaahgjdvqc30482.jpg "/>

So how does it work? With Sgid you can solve this collaborative work!

• By default, when a user creates a file, it is the primary group that belongs to the user;

• When a directory is set to Sgid permissions, a user who has write permission to this directory is created in this directory by a group of genera that belong to the directory, not the user's base group

• sgid permission set

  • chmod g+s Directory ...

  • chmod g-s Directory ...

  • s, S difference with suid

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M00/72/B5/wKiom1Xrz2TQz0KSAAIJ8V786co726.jpg "title=" Baidushurufa_2015-9-6_13-28-53.png "alt=" Wkiom1xrz2tqz0ksaaij8v786co726.jpg "/>

STICKY

When we solve the principle of sgid, then to consider a problem, in a collaborative working directory, the user is able to delete someone else's file [the principle of deletion has been described in the knowledge store], then how to achieve collaborative work scenarios each user can edit the file but does not allow the deletion of other people's files, Only allow to delete your own files?

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M00/72/B6/wKiom1Xr0GaDWzSxAAHudAJG1gs487.jpg "title=" Baidushurufa_2015-9-6_13-34-22.png "alt=" Wkiom1xr0gadwzsxaahudajg1gs487.jpg "/>

This is the last sticky of 3 special permissions, and to a certain extent ensures security.

• To a public writable directory, everyone can write their own files, but cannot delete the permissions of others

• Permission settings for sticky

  • • chmod o+t Directory ...

    • chmod o-t Directory ...
      

This article is from the "Blue Warehouse" blog, be sure to keep this source http://bluebox.blog.51cto.com/8852456/1691887

[8-30] Special permissions on Linux file systems (SUID, SGID, Sticky)