Special permissions for Linux sticky, sgid and data security

Tag:linux   sgid   sticky    special permission    

    Linux There is a special directory in the system /tmp Known as a temporary directory, all users can create files in the directory, which means that /tmp rwxrwxrwx use special permissions sticky: Sticky bit ( Span style= "font-family: ' The song Body '; > adventure bit ) () file. However, due to the average user's umask 0002. ordinary users in /tmp creating a directory and storing your temporary files in that directory is not safe. Sticky /tmp The file in the directory is secure and does not guarantee /tmp

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M00/3F/85/wKioL1PKYG7BD6UlAABpuzco6sI791.jpg "title=" Sticky.png "alt=" Wkiol1pkyg7bd6ulaabpuzco6si791.jpg "/>

[Email protected] ~]$ umask0002

Create a mytest directory in the /tmp directory using the normal user system .

[Email protected] tmp]$ mkdir/tmp/mytest[[email protected] tmp]$ ll-d mytestdrwxrwxr-x. 3 System system 4096 Jul 4 15:18 mytest

Description

because the average user's umask value is:0002, the directory permissions created are represented as:rwxrwxr-x.

users can create and delete files in a directory, depending on whether the user has written in that directory (r) permissions. We can, too, understandthat one of the important philosophical ideas of Linux is "all documents." The directory is also one of the files. Consider a directory as a file. Then, when a user creates a file in the directory, it is equivalent to adding a row of data to the directory file, and deleting the file in that directory is equivalent to deleting the data row from the catalog file. Therefore, the user to the directory ( directory file ) to create a file or delete a file, the directory must have write permission to be able.

according to the "Rights matching model" whenever you initiate a file creation The genus or additional group of the user (Touch,vim or delete file (RM) process is System. then the user can delete or create the file.

Let's see if it's the same as the analysis.

1, the User:the Basic group of system as user Admin,hadoop additional group

This allows the user: Admin,hadoop to create the file in the mytest directory.

[[email protected] tmp]# usermod-a-G systemadmin[[email protected] tmp]# usermod-a-G Systemhadoop[[email protected] TM p]# ID adminuid=500 (Admin) gid=500 (Admin) groups=500 (Admin), 501 (System) [[email protected] tmp]# ID hadoopuid=4029 ( Hadoop) gid=4029 (Hadoop) groups=4029 (Hadoop), 501 (System)

2. Create files in the /tmp/mytest directory, respectively, as admin and Hadoop user

[Email protected] tmp]# su–hadoop-c ' touch/tmp/mytest/hadoop.txt ' [[email protected] tmp]# su-admin–c ' touch/ Tmp/mytest/admin.txt '

3.See if you can create a file?

[email protected] tmp]# ll mytesttotal 4-rw-rw-r--. 1 Admin admin 0 Jul 16:51 admin.txt-rw-rw-r--. 1 Hadoop hadoop 0 Jul 16:51 hadoop.txt

Analysis:

from the "ls mytest" Display results, know the User:admin,hadoop created the file successfully.

4, and then as the Admin user's identity to delete the main Hadoop files and as a hadoop user to delete the main admin-owned files

Before deleting

[Email protected] ~]# ll/tmp/mytesttotal 4-rw-rw-r--. 1 Admin admin 0 Jul 16:51 admin.txt-rw-rw-r--. 1 Hadoop hadoop 0 Jul 16:51 hadoop.txtdrwx------. 2 root root 4096 Jul 4 15:18 Skel

Perform a delete operation

[Email protected] ~]# su-admin-c ' rm-r/tmp/mytest/hadoop.txt ' [[email protected] ~]# su-hadoop-c ' rm-r/tmp/mytest /admin.txt '

After the delete

[Email protected] ~]# ll/tmp/mytesttotal 4drwx------. 2 root root 4096 Jul 4 15:18 Skel

Analysis:

from the above "ll/tmp/mytest" results, learned. The user admin initiating the delete process matches the genus of the directory where Hadoop and the deleted files are located. It can be deleted

So, look at the files created by the administrator in the/tmp/mytest directory, can ordinary users delete them?

create a file as an administrator Root.txt

[Email protected] ~]# touch/tmp/mytest/root.txt[[email protected] ~]# ll/tmp/mytesttotal 4-rw-r--r--. 1 root root 0 Jul 15:50 root.txtdrwx------. 2 root root 4096 Jul 4 15:18 Skel

Start rm process with normal user admin to delete files created by Administrator Root.txt

[Email protected] ~]# su-admin-c ' rm-f/tmp/mytest/root.txt '

Check to see if the file has been deleted

[Email protected] ~]# ll/tmp/mytesttotal 4drwx------. 2 root root 4096 Jul 4 15:18 Skel

Analysis:

The results shown from "ll/tmp/mytest" are known. The normal user has removed the Root.txt file that is the owner of the administrator (root) and the admin user does not have permission to write (R) . Again, the ability to delete files in the directory depends on whether the user initiating the delete process has write permission to the directory where the deleted files are located.

from the experimental results above , it is safe to say that the files created in/tmp/mytest are free of any security.

Umask = 0002 for ordinary users . Like the example above,the additional group for the Admin user is system, and the additional group for the Hadoop user is system. the System user ( which belongs to the system Group ) is created in the/tmp directory. The data in this directory is very insecure.

If, if you want, the user who initiated the delete process cannot delete a file that is not owned by the owner, you will have to add a special control bit sticky ( sticky bit ) to the directory. Add the following method:

Before adding sticky

[Email protected] ~]# ll-d/tmp/mytestdrwxrwxr-x. 3 System system 4096 Jul 1916:01/tmp/mytest

To add a sticky bit using the "chmod" command

[Email protected] ~]# chmod o+t/tmp/mytest

After adding sticky , the other permissions on the directory become "T" on the last one.

[Email protected] ~]# ll-d/tmp/mytestdrwxrwxr-t. 3 System system 4096 Jul 1916:01/tmp/mytest

Test if you can delete files that are not owned by the owner?

Files in the/tmp/mytest directory

[Email protected] ~]# ll/tmp/mytesttotal 4-rw-rw-r--. 1 Hadoop hadoop 0 Jul 16:45 hadoop.txt-rw-r--r--. 1 root root 0 Jul 16:01 root.txt

initiate the RM process as Admin user to delete files belonging to the primary Hadoop and root users

[[email protected] ~]# su-admin-c ' rm-f/tmp/mytest/hadoop.txt ' rm:cannot remove '/tmp/mytest/hadoop.txt ': Operation not Permitted[[email protected] ~]# su-admin-c ' rm-f/tmp/mytest/root.txt ' rm:cannot remove '/tmp/mytest/root.txt ': Operati On not permitted

from the result : It can be seen that the owner is not his own file. safety is ensured using the sticky ( dip bit ) .

or because the average user's umask = 0002, then the permissions of the user-created file are : rw-rw-r-

User admin, The additional group for Hadoop is system. Therefore,the system user (which belongs to the system Group ) is in the /tmp

directories or files created in/tmp/mytest in the example above , user admin,Hadoop can be modified.

Example:

[Email protected] ~]# su-system-c ' touch/tmp/system.txt '

Write Data as Admin user to System.txt of Master System

[[email protected] ~]$ echo "I admin" >>/tmp/system.txt[[email protected] ~]$ Cat/tmp/system.txti admin

Add,sticky bit Obviously can not delete the owner is not his own files, but also can modify the owner is not his own files. This is because when we create a file, the permissions for the file are based onthe value of "Umask". So do not want to let other users modify their own files, the file belongs to the group and other write permission bits removed.

due to userAdmin, the additional group for Hadoop is the Direct group Systm of the user system. so all two users can modify files that belong to the system . However , the owner of the file is admin, the user Hadoop,the system can not be modified.

Files that are also owned by users of Hadoop are also not modifiable by the other two users. When a user creates a file, the owner and the group are the user name and group name of the user who created it, and it has no relation to the directory in which it resides. Therefore, only through the administrator to modify , belong to the main admin,hadoop files belong to the group system. This makes it possible to modify each other's own files that are not the owner. Is it possible, in some way, that when a user creates a file, the group of the file is the genus of the directory in which the file resides? This is done through "sgid" special permissions.

Let's see how it's implemented:

[[email protected] ~]# ID systemuid=501 (System) gid=501 (System) groups=501 (System) [[email protected] ~]# ID adminuid=500 (admin) gid=500 (Admin) groups=500 (Admin), 501 (System) [[email protected] ~]# ID hadoopuid=4029 (Hadoop) gid=4029 (Hadoop) groups=4029 (Hadoop), 501 (System) [[email protected] ~]# ll/tmp/mytesttotal 4-rw-rw-r--. 1 Admin admin 0 Jul 17:15 admin.txt-rw-rw-r--. 1 Hadoop hadoop 0 Jul 16:45 hadoop.txt-rw-rw-r--. 1 System System 0 Jul 16:52 System.txt

Modify the file hadoop.txt that belongs to Hadoop, and the modification fails.

[[email protected] ~]$ echo "I admin" >/tmp/mytest/hadoop.txt-bash:/tmp/mytest/hadoop.txt:permissiondenied

after adding a special permission GUID to/tmp/mytest , see if we can modify each other's files that belong to the owner?

before you add special permissions Sgid

[Email protected] ~]# ll-d/tmp/mytestdrwxrwxr-t. 3 System system 4096 Jul 1917:15/tmp/mytest

Add special Permissions Sgid

[Email protected] ~]# chmod g+s/tmp/mytest

After adding special permissions Sgid , the third digit of the genus Group is represented as "s"

[Email protected] ~]# ll-d/tmp/mytestdrwxrwsr-t. 3 System system 4096 Jul 1917:15/tmp/mytest

look at the creation of the file after adding Ugid, what changes are there in the group of files?

Create files individually as different user identities

[Email protected] ~]# su-system-c ' touch/tmp/mytest/system.txt ' [[email protected] ~]# su-admin-c ' touch/tmp/mytest/ Admin.txt ' [[email protected] ~]# su-hadoop-c ' touch/tmp/mytest/hadoop.txt '

Viewing the result of creating a file, the group of three user-created files is no longer the group name of the user who created the file.

It is the group of directories in which the files are located. So that they can belong to each other as the Lord is not their own document.

[Email protected] ~]# ll/tmp/mytesttotal 4-rw-rw-r--. 1 Admin System 0 Jul 17:50 admin.txt-rw-rw-r--. 1 Hadoop system 0 Jul 17:50 hadoop.txt-rw-rw-r--. 1 System System 0 Jul 17:50 System.txt

based on the "rights matching model" user admin,Hadoop is attached as system. the group of files is also system.

and has read and write permissions. So they must be able to modify each other The master is not his own file, but can not delete the owner is not his own file because of the sticky bit.

This article is from the "Linux" blog, so be sure to keep this source http://9528du.blog.51cto.com/8979089/1440295

Special permissions for Linux sticky, sgid, and data security