Linux study notes - day5 (3.16 draft, 3.19 supplement)-------UID and GID, group management, ACL

Foreword: 3.16 draft, unreleased. 3.19 Supplementary content, published.

text:

Each file has the attributes of owner and group, and each logged-in user will get at least two IDs, one is the user ID (User ID, UID),

One is the group ID (Group ID, GID).

When we log in to the Linux host, enter the account number and request to display file attributes, the system will find the account and group name corresponding to the UID and GID according to the contents of /etc/passwd and /etc/group and then display it.

So, what does the system do when we log in to the host to get the shell environment?

1. First find out if there is an account you entered under /etc/passwd. If not, jump out, if there is, read the UID and GID (location above) corresponding to the account. There are also the account's home directory and shell configuration.

2. Check the password table. Linux enters /etc/shadow to find the corresponding account and UID, and verify.

3. Enter the shell control.


/etc/passwd file structure

Example: (root account)

root:x:0:0:root:/root:/bin/bash This is an account.

root account x password 0 UID 0 GID root user information description column /root home directory /bin/bash : Shell

Note (the reason why it is displayed as x here is because the password data is easy to be stolen and placed in /etc/shadow)

/etc/shadow file structure

Example:

root:$6$SqKt7MI2rBevNX9Y$qMt99CQMQWcdyEmbN9iH0fzXZd/A1f0bmI9blfXRWMuYsamKI3Dri4Zr.lDkTWDnjqQ2z/p2bglynWL80vDYM0:17606:0:99999:7:::

$SqKt7MI2rBevNX9Y$ : This is the impurity (salt), which is an encryption used to prevent the password from being cracked. Disorder and change the password, causing an avalanche effect.

Account management

useradd

-u: followed by UID, which is a set of numbers. Give a specific UID directly to this account

-g: The group name that follows.

-G: Followed by the groups that this account can also join

-M: Force not to create user home directory

-m: Force creation of user home directory

-r : Create a system account, the UID of this account will be limited

-s : followed by shell

Chestnut:

Create a user with full default values


The user's home directory will be created by default, and the permission is 700


We use the default value to create, in fact, centos will help us with several items:

Create a line of account-related data in /etc/passwd, including creating UID/GID/home directories, etc.;
fill in the password-related parameters of this account in /etc/shadow, but there is no password yet;
in /etc/group Add a group name that is exactly the same as the account name;

Create a directory with the same name as the account under /home as the user's home directory, and the permission is 700

Chestnut:: Suppose I already know that there is a group named users in my system, and UID 700 does not exist, please use users as the initial group and uid 700 to create an account named user2

-u: followed by UID, which is a set of numbers. Give a specific UID directly to this account

-g: The group name that follows.

Chestnut: Create a system account, user3


As you can see, user3 does not have a home directory.

passwd

After just creating an account with useradd, the account is temporarily blocked by default. Configure him directly with a new password.

-stdin : Pass the data from the previous pipe as the password input.      

-l : the meaning of lock. Add the second column of /etc/shadow to the front to make the password invalid

-u:unlock

-S : List password-related parameters, that is, most of the information in the shadow file

-n: followed by the number of days. The fourth field of shadow is how long the password cannot be modified.

-X : followed by the number of days. The fifth field of shadow, how long must the password be changed

-W : followed by the number of days, the sixth field of shadow, the number of warning days before the password expires

-i : followed by the date, the seventh field of shadow, the password expiration date

Chestnut: root adds a password to User2


The prompt password is too simple, but the modification is successful. This is the power of root account modification.

 Added (3.19): echo '111111' | passwd -stdin user1


usermod (usually modified directly in the configuration file)

userdel delete

userdel  -r  user2

Even the home directory is deleted.

id (supplemented in 3.19)
id This command can query the relevant UID/GID information of someone or yourself, and use the id to list them all


What about just showing the UID?


User1 is not displayed, only UID is displayed


groupadd 

-g : followed by a specific GID

-r : create system group


ACL

scenes to be used:

myuser1 is the assistant of the projecta project, he needs the content of this project, but he "cannot modify" any data in the project directory! How should that be? You might be able to do this:

Add myuser1 to the support of the projecta group, but this will allow myuser1 to have full /srv/projecta permissions, and myuser1 can delete any data in this directory! This is problematic;
change the permissions of /srv/projecta to 775 so that myuser1 can access the data. But at this point, there will be troubles where everyone else can enter the directory and look up! This is not the environment we want either.


Provides detailed permission configuration other than the traditional owner, group, and others read, write, and execute permissions.

getfacl : Get the acl configuration item of a file or directory

setfacl : configure the acl specification of a directory and file

setfacl command usage

-m : configure subsequent acl parameters for file use

-k : remove subsequent acl parameters

-b : remove all acl configuration parameters

-k : remove default acl parameters

-R : recursively configure acl, that is, the subdirectories will be configured

-d : Configure the meaning of the default acl parameters. Only valid for the directory, new data in the directory will refer to this default value.


1. The way for a specific user

Specification: u: List of user accounts: rwx

Chestnut: The permission specification for User1 is rx

Premise: touch acl_test1 user1 created

setfacl -m u:user1:rx  acl_test1


No user list, representing the owner of the configuration file.


The above is the simplest ACL configuration, which is configured using the method of "u:User:Permission"! Please add the -m option before configuration. If a file is configured with ACL parameters, its permission part will have a + sign! But at this time, the permissions you see may be a little different from the actual permissions!

This needs to be done through getfacl.

getfacl command usage


It can be clearly seen from the picture: User: User1: rx is displayed.

Ways for specific groups:

Configuration specification: "g:[group list]:[rwx]", such as permission specification rx for mygroup1


Configuration method for effective permission mask:

Configuration specification: "m:[rwx]", for example, the specification for the file just now is only r


bitwise AND of user:user1 and mask

group:users and mask bitwise AND

Finally got real permissions: r--

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325813427&siteId=291194637