Shulou(Shulou.com)06/01 Report--

This article introduces the relevant knowledge of "introduction of advanced user groups and permissions in Linux". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Let's take a look at four files about users and groups.

/ etc/passwd

/ etc/shadow

/ etc/group

/ etc/gshadow

First, let's take a look at the file / etc/passwd.

This file only stores the user's information.

[root@localhost ~] #

[root@localhost ~] # cat / etc/passwd | grep user1

User1:x:500:500::/home/user1:/bin/bash

[root@localhost ~] #

There are a total of seven fields. Learn the meaning of each field.

User1 user name

The password bit of the X user (if this bit does not have the X above, it means that the login user does not need a password)

500 UID

500 GID

The fifth is the description of the password, which is not available here.

/ home directory of / home/user1 user

/ shell of bin/bash user

There is a special shell / sbin/nologin here.

If you change the user's shell to / sbin/nologin, then the user can only log in to the service, but not the computer. Interactive login is not allowed.

Let's take a look at the file / etc/shadow.

This file is mainly used to save the user's password information and policies.

[root@localhost ~] #

[root@localhost ~] # cat / etc/shadow | grep user1

User1:$1 $2WJEp9K7 $h.NRfJsaEm8VMksBQHZm7.V14668-0VOV99999-7:

[root@localhost ~] #

Now let's understand the meaning of each field.

User1 user name

The second field is to hold the user's password, which is encrypted by MD5.

If there is a! in front of the password bit, it means the user is locked.

14668 time when the password was last modified

The minimum survival period of 0 password (0 means the user can change the password at any time)

99999 password expiration time (99999 means the password never expires)

7 password expiration warning days (warn the user seven days before the password expires)

Let's take a look at the file / etc/group.

This file is mainly used to store group information.

[root@localhost ~] #

[root@localhost ~] # cat / etc/group | grep user1

User1:x:500:

[root@localhost ~] #

Now let's understand the meaning of each field.

Name of the User group

Password bits of group X

500 GID

You can add the user directly after the colon, which means you have joined the group.

Finally, let's look at the file / etc/gshadow.

The main purpose of this file is to save the group password information.

[root@localhost ~] #

[root@localhost ~] # cat / etc/gshadow | grep user1

User1:!::

[root@localhost ~] #

Name of the User group

As you can see, this group does not have a password by default, so now let's set a password for it.

[root@localhost ~] #

[root@localhost ~] # gpasswd user1

Changing the password for group user1

New Password:

Re-enter new password:

[root@localhost ~] # cat / etc/gshadow | grep user1

User1:$1$ ZxvTf/dQ$DWmf//MTxpwJIzTZIcYQZ/::

[root@localhost ~] #

As you can see, the group now has a password, which is also encrypted by MD5.

Let's take a look at the meaning of the group's password.

[root@localhost ~] #

[root@localhost ~] # useradd user2

[root@localhost ~] #

[root@localhost ~] # su-user2

[user2@localhost ~] $

[user2@localhost ~] $newgrp user1

Password:

[user2@localhost ~] $id

Uid=501 (user2) gid=500 (user1) groups=500 (user1), 501 (user2)

[user2@localhost ~] $

As you can see, we, user2, have now joined user1 and become members of the user1 group. In other words, the meaning of group passwords is that as long as an ordinary user has a group password, he can join this group and become a member of this group.

User management tool

Useradd add user

# useradd user1 (user name)

[root@localhost ~] #

[root@localhost ~] # useradd user1

[root@localhost ~] #

[root@localhost ~] # id user1

Uid=502 (user1) gid=502 (user1) groups=502 (user1)

[root@localhost ~] #

User1 is added successfully.

Usermod modifies user

Userdel Delete user

# userdel-r user1 (user name)

[root@localhost ~] #

[root@localhost] # userdel-r user1

[root@localhost ~] #

[root@localhost ~] # id user1

Id: user1: No such user

[root@localhost ~] #

User1 was deleted successfully.

-r delete the user's / home directory while deleting the user.

About the tools to monitor the landing

# w

[root@localhost ~] # w

15:27:32 up 15:31, 3 users, load average: 0.81, 0.25, 0.08

USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT

Root: 0-21Feb10? xdm? 3:07 0.30s / usr/bin/ gnome-

Root pts/2: 0.0 15:27 0.00s 0.06s 0.01s w

Root pts/1 192.168.0.20 15:27 13.00s 0.05s 0.05s-bash

[root@localhost ~] #

You can see 192.168.0.20 connecting me.

# last

[root@localhost ~] #

[root@localhost ~] # last

Root pts/2 station20.exampl Sun Feb 28 15:32 still logged in

Root pts/1: 0.0 Sun Feb 28 15:31 still logged in

Root pts/2: 0.0 Fri Feb 26 17:21-00:32 (1 minute 07 10)

Root pts/1: 0.0 Mon Feb 22 23:07-21:46 (3'22 38)

Root pts/2: 0.0 Mon Feb 22 18:31-23:07 (04:36)

Root pts/2: 0.0 Mon Feb 22 14:33-14:33 (00:00)

Root pts/1: 0.0 Sun Feb 21 17:33-18:31 (1000 Sun Feb 57)

Root pts/1: 0.0 Sun Feb 21 17:28-17:33 (00:04)

Root pts/1: 0.0 Sun Feb 21 13:30-17:28 (03:57)

Root: 0 Sun Feb 21 13:30 still logged in

Root: 0 Sun Feb 21 13:30-13:30 (00:00)

Reboot system boot 2.6.18-164.el5 Sun Feb 21 13:29 (70.02 03)

Root pts/1: 0.0 Sun Feb 21 21:22-down (- 7 down Murray 54)

Root: 0 Sun Feb 21 21:21-down (- 7 down Murray 54)

Root: 0 Sun Feb 21 21:21-21:21 (00:00)

Reboot system boot 2.6.18-164.el5 Sun Feb 21 21:17 (- 7 Murray 50)

Reboot system boot 2.6.18-164.el5 Sun Feb 21 21:14 (00:02)

Wtmp begins Sun Feb 21 21:14:07 2010

[root@localhost ~] #

Those users have logged on to my computer. And how long it has been logged on my computer, a lot of things can be seen.

# lastb

[root@localhost ~] #

[root@localhost ~] # lastb

Root ssh:notty www.google.com. Mon Feb 22 15:50-15:50 (00:00)

Root ssh:notty www.google.com. Mon Feb 22 15:50-15:50 (00:00)

Root ssh:notty www.google.com. Mon Feb 22 15:50-15:50 (00:00)

Btmp begins Mon Feb 22 15:50:50 2010

[root@localhost ~] #

The result of this command is that those computers have logged on to my computer, but have not logged in successfully. Only the information that did not log in successfully will be displayed, and there is a lot of detail about how they tried to connect to my computer.

Default permissions (defaults perm)

By default, when we create files and directories, we do not inherit the permissions of the parent directory, but based on the UMASK value of the directory and file.

About the UMASK value

Is used to define the default permissions of the file

How to query the UMASK value in the system?

# umask

[root@localhost ~] #

[root@localhost ~] # umask

0022

[root@localhost ~] #

As you can see, the umask value in the system is 0022

Of course, this umask can also be modified.

# umask 0033

[root@localhost ~] #

[root@localhost ~] # umask 0033

[root@localhost ~] #

[root@localhost ~] # umask

0033

[root@localhost ~] #

The umask value of the system has been changed to 0033.

How does Umask define permissions for directories and files

Umask definitions are different for different users.

For root UAMSK value is 022

For ordinary users, the umask value is 002.

So what are our default permissions when creating directories and files?

For root directories 777-022 755

Document 666-022 644

For ordinary user directories 777-002 775

Document 666-002 664

This is our default permission to create directories and files.

Note: when we subtract the umask value with the highest authority, we must subtract it with a binary value, not a decimal value.

[root@localhost ~] #

[root@localhost ~] # umask

0022

[root@localhost ~] # mkdir test

[root@localhost ~] # touch test1

[root@localhost ~] # ll | grep test

Drwxr-xr-x 2 root root 4096 Feb 28 16:42 test

-rw-r-r- 1 root root 0 Feb 28 16:43 test1

[root@localhost ~] #

As you can see, the default permission for our directory is indeed 755. The default permission for the file is indeed 644.

[root@localhost ~] #

[root@localhost ~] # su-user1

[user1@localhost ~] $

[user1@localhost ~] $umask

0002

[user1@localhost ~] $mkdir file

[user1@localhost ~] $

[user1@localhost ~] $touch file1

[user1@localhost ~] $ll | grep file

Drwxrwxr-x 2 user1 user1 1024 Feb 28 16:44 file

-rw-rw-r- 1 user1 user1 0 Feb 28 16:44 file1

[user1@localhost ~] $

As you can see, under the identity of an ordinary user. The permissions for the directory we created are 775 and the permissions for files are 664.

About three special permissions

1. Suid permission

If suid is used in an executable file (command or script), then anyone who executes the command will have temporary owner rights to the command.

We know that the passwd command can be run by administrators as well as by ordinary users.

And if we use passwd to change the password successfully, we have to add a password bit to the / etc/shadow file, now let's look at the permissions of this file.

[root@localhost ~] #

[root@localhost ~] # ls-l / etc/shadow

-Rmurmuri-1 root root 1050 Feb 25 23:01 / etc/shadow

[root@localhost ~] #

You can see that ordinary users in this file do not have any permissions, not even read permissions, so how do ordinary users change their passwords and be able to write their passwords in the / etc/shadow file?

[root@localhost ~] #

[root@localhost ~] # ll / usr/bin/passwd

-rwsr-xr-x 1 root root 22960 Jul 17 2006 / usr/bin/passwd

[root@localhost ~] #

We can see that the permission bit of the passwd command has an extra s, which we have never seen before, and this is suid.

When the ordinary user uses passwd to change the password, because the passwd command has suid permission, then the ordinary user will temporarily have the permission of root, the owner of the command, so that the password bit can be written into the / etc/shadow file.

Now there is another question: if ordinary users can change their passwords because of suid, can ordinary users change other users' passwords? let's give it a try.

[user1@localhost ~] $

[user1@localhost ~] $passwd user2

Passwd: Only root can specify a user name.

[user1@localhost ~] $

We can see that it cannot be modified. If, in theory, our passwd command has suid permission, it is possible to change the password of another user. It's not that the passwd command doesn't have the suid function, and it doesn't report permission denials. Instead, it prompts us that only root users can attach the user name to the command passwd. The system has made restrictions on syntax, not suid, and has no effect. This is also the system to ensure security.

We're doing an experiment to understand the role of suid.

First, let's take a look at the permissions of the root in the system.

[root@localhost ~] #

[root@localhost ~] # ls-ld /

Drwxr-xr-x 25 root root 4096 Feb 28 00:30 /

[root@localhost ~] #

As you can see, the permission of the root is 755, that is to say, an ordinary user has no way to write data to the root, does the ordinary user belong to someone else? Let's try.

[root@localhost ~] #

[root@localhost ~] # su-user1

[user1@localhost ~] $

[user1@localhost ~] $cd /

[user1@localhost /] $mkdir test

Mkdir: cannot create directory `test': Permission denied

[user1@localhost /] $

As you can see, our normal user, user1, does not have write permission to the root.

Now let's add a suid permission to the mkdir command. Let's see what happens.

[root@localhost ~] #

[root@localhost ~] # which mkdir

/ bin/mkdir

[root@localhost ~] # ll / bin/mkdir

-rwxr-xr-x 1 root root 29852 Jul 13 2009 / bin/mkdir

[root@localhost ~] #

[root@localhost ~] # chmod Utility / bin/mkdir

[root@localhost ~] #

[root@localhost ~] # ll / bin/mkdir

-rwsr-xr-x 1 root root 29852 Jul 13 2009 / bin/mkdir

[root@localhost ~] #

As you can see, the permission of the mkdir command has been added with an s permission.

Now we are using a normal user to create a file under the root

[root@localhost ~] #

[root@localhost ~] # su-user1

[user1@localhost ~] $

[user1@localhost ~] $cd /

[user1@localhost /] $mkdir file

[user1@localhost /] $

[user1@localhost /] $ll-ld file/

Drwxrwxr-x 2 root user1 4096 Feb 28 21:58 file/

[user1@localhost /] $

Now we can create a directory under the root, because we ordinary users temporarily become the permissions of the owner of the command when using the command mkdir, and all ordinary users can create a directory under the root. We can also see that we create a file under the root through user1, and its owner is also root, which also shows that we do use the identity of root to create the file directory.

There is another problem. Because of the addition of an s bit in our mkdir command, where is the previous x bit permission? If it's S, it means you didn't have x permission before. if it's s, it means you used to have x permission.

[root@localhost ~] #

[root@localhost ~] # ll / bin/mkdir

-rwsr-xr-x 1 root root 29852 Jul 13 2009 / bin/mkdir

[root@localhost ~] # chmod Umurx / bin/mkdir

[root@localhost ~] # ll / bin/mkdir

-rwSr-xr-x 1 root root 29852 Jul 13 2009 / bin/mkdir

[root@localhost ~] # chmod uplix / bin/mkdir

[root@localhost ~] # ll / bin/mkdir

-rwsr-xr-x 1 root root 29852 Jul 13 2009 / bin/mkdir

[root@localhost ~] #

As you can see, when we remove the x permission, it becomes S, and when we add the x permission, it becomes s again.

2.sgid permission

Just now our suid can only be applied to one binary file, that is, commands.

And our sgid can be used in commands and directories.

Let's first take a look at the use of sgid in commands.

If it is allowed to be used on a command, just like the suid just now, it only temporarily has the permission of the command to have the group, and that's the difference.

Next, let's take a look at the application of sgid in the directory.

If sgid permissions are applied to a directory, the files and directories created by anyone in that directory will inherit the groups of the directory itself.

Now let's use an experiment to understand the permissions of sgid.

[root@localhost ~] #

[root@localhost ~] # mkdir / redhat

[root@localhost ~] #

[root@localhost ~] # chmod 777 / redhat/

[root@localhost ~] #

[root@localhost ~] # ll-ld / redhat/

Drwxrwxrwx 2 root root 4096 Mar 1 21:26 / redhat/

[root@localhost ~] #

Now we have created a new redhat directory, and the permission of this directory is 777. now ordinary users should also have the permission of rwx to this directory. Let's try it.

[root@localhost ~] #

[root@localhost ~] # su-user1

[user1@localhost ~] $

[user1@localhost ~] $cd / redhat/

[user1@localhost redhat] $

[user1@localhost redhat] $touch 1.txt

[user1@localhost redhat] $ls

1.txt

[user1@localhost redhat] $

We can indeed create a file, so who will be the owner and ownership group of the file? it must be user1. Now let's add a sgid permission to this directory.

[root@localhost ~] #

[root@localhost ~] # chmod gears / redhat/

[root@localhost ~] #

[root@localhost ~] # su-user1

[user1@localhost ~] $

[user1@localhost ~] $cd / redhat/

[user1@localhost redhat] $

[user1@localhost redhat] $touch 2.txt

[user1@localhost redhat] $

[user1@localhost redhat] $ll

Total 0

-rw-rw-r- 1 user1 user1 0 Mar 1 21:28 1.txt

-rw-rw-r- 1 user1 root 0 Mar 1 21:30 2.txt

[user1@localhost redhat] $

When I add a sgid permission to the redhat directory, the file ownership group that we use ordinary users to create in the redhat directory becomes root.

Now let's understand the permissions of sgid. When we use the permissions of sgid on the redhat directory, the ownership group of the files created by the ordinary user user1 under the redhat directory will inherit the group of the redhat directory itself and will not change with the user.

Also, as just now, s will be displayed if you have x permission, and S will be displayed if you don't have x permission.

3. Sticky permission

Sticky can only be used on directories.

If sticky permission is applied to a directory, only the root user and the owner of the file can delete the files in that directory.

Now let's go through an experiment to learn about sticky permissions.

[root@localhost ~] #

[root@localhost ~] # ls-ld / redhat/

Drwxrwxrwx 3 root root 4096 Mar 1 21:48 / redhat/

[root@localhost ~] #

The permission of the Redhat directory is 777. now ordinary users should be able to create files in this directory. Let's try it.

[root@localhost ~] #

[root@localhost ~] # su-user1

[user1@localhost ~] $cd / redhat/

[user1@localhost redhat] $touch 1.txt

[user1@localhost redhat] $ls

1.txt

[user1@localhost redhat] $

We use user1 to create a 1.txt file in this directory, so can our user2 delete this file, because our directory permission is 777, all our ordinary users user2 have w permission to this directory, w permission means you can create and delete files in this directory. Let's try it.

[root@localhost ~] #

[root@localhost ~] # su-user2

[user2@localhost ~] $

[user2@localhost ~] $cd / redhat/

[user2@localhost redhat] $

[user2@localhost redhat] $ls

1.txt

[user2@localhost redhat] $rm-rf 1.txt

[user2@localhost redhat] $ls

[user2@localhost redhat] $

OK, there is no problem, we can indeed delete the file 1.txt created by user1.

Now let's add a sticky to the redhat directory and see what happens.

[root@localhost ~] #

[root@localhost ~] # chmod ostent / redhat/

[root@localhost ~] # ls-ld / redhat/

Drwxrwxrwt 2 root root 4096 Mar 1 23:19 / redhat/

[root@localhost ~] #

As you can see, the redhat directory has added a t permission, which is the sticky permission.

As above, t is displayed if you have x permission. If there is no x permission, T is displayed.

We are creating a file using user1 and then deleting it using user2

[root@localhost ~] #

[root@localhost ~] # su-user1

[user1@localhost ~] $

[user1@localhost ~] $cd / redhat/

[user1@localhost redhat] $

[user1@localhost redhat] $touch 2.txt

[user1@localhost redhat] $

[user1@localhost redhat] $ls

2.txt

[user1@localhost redhat] $su-user2

Password:

[user2@localhost ~] $cd / redhat/

[user2@localhost redhat] $ls

2.txt

[user2@localhost redhat] $rm-rf 2.txt

Rm: cannot remove `2.txtreply: Operation not permitted

[user2@localhost redhat] $

As you can see, now we use user1 to create files, user2 cannot be deleted.

That's what sticky permissions are for.

When a sticky permission is added to a redhat directory, only the root user and user1 can delete the 2.txt file that user1 creates in the redhat directory.

There is a directory in our system that uses sticky permissions.

[root@localhost ~] #

[root@localhost ~] # ls-ld / tmp/

Drwxrwxrwt 15 root root 4096 Feb 28 00:28 / tmp/

[root@localhost ~] #

Our / tmp directory has sticky permission by default.

Our special permissions can also be expressed in numbers.

Suid 4

Sgid 2

Sticky 1

Summary:

Suid permissions are used on commands and can only be used on users.

Sgid permissions are used on commands and directories, and can only be used on groups.

Sticky permissions are used on directories and can only be used on others.

This is the end of the introduction of "introduction to advanced user groups and permissions in Linux". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.