Linux team development permission management documentary

Author: fbysss
MSN: jameslastchina@hotmail.com
Blog: blog.csdn.net/fbysss
Disclaimer: This article is original from fbysss. for reprinting, please indicate the source
Keyword: Linux permission management

Background

In the previous development server, everyone logged on with the root account. At the beginning, it was very nice and free to use, and no problems were found. However, the problems of file loss and database startup failure gradually become an urgent task. In fact, it is only a simple reboot, shutdown, or RM command, which is very destructive. Moreover, misoperations are hard to locate. Root can only be controlled by a few people.

I. Team building environment, file read/write sharing
The project code is located under/SVN/prj. The code is updated through SVN up and ant is called for compilation and deployment. Therefore, the prj directory is readable and writable for everyone.
We know which user is used to log on. The newly created file host is the current user. The default file permission is 644 (-RW-r --). Li Si cannot delete the files updated from the code repository or the class files generated after compilation. The execution of ant clear will inevitably fail. Every time chmod is used to modify the corresponding file, it is not a problem. What should I do?
The goal is clear: we hope that in the development team, the permissions of every developer are equal, and any new file can be read and written by others.
DecompositionThere are two things to come out:
1. The directory/SVN/prj should belong to the development team, that is, a user group. This is simple. Create a group, such as Dev, and use chown.
# Gruopadd Dev
# Useradd zhangshan

# Useradd Lisi
# Useradd zhangsan-G Dev

# Useradd Lisi-G Dev
# Chown-R: DEV/SVN/prj
Here we must note that-G and-G are different. -G is what you naturally understand. Add a user to a group or multiple groups (separated by commas. What about-G?

Set the GID of the user. That is, the initial group (initial group) after the user logs in ).
Using the ID zhangsan command, you can see that uid = zhangsantest, gid = Dev, groups = zhangsan, Dev. Or use groups zhangsan. The result is zhangsan Dev.
Note that when you create a user, a group with the same name is created by default. If the-G parameter is not added, GID is the ID of the group. Create a file and the Group belongs to the group with the same name as the user. Therefore, both-G and-G are indispensable.
2. Change the default permission for file creation to 664 (-RW-r --).

This involves umask, which is used to control the permissions for creating files or directories by default. You can use the umask command to directly modify the settings. In our Linux environment, the default umask is 022.
Umask: If this parameter is set to 1, no one has the permission. Who has the permission to open it. Except for files, it can be up to 666 (no execution permission by default ). The directory can go to 777
For example, if umask is set to 022, the directory can be up to 755, umask is 002, And the directory can be up to 775
Solution:Each user will execute some initialization scripts to modify the user's umask in the script.
The script snippets are as follows:
Usergroup = '/usr/bin/ID-GN $ user'
Echo $ usergroup | grep-Q Dev
If [$? -EQ 0]; then
Umask 0002
Fi
The meaning is very simple. I will not repeat it here. In Linux, it should be placed in/etc/bashrc, rather than/etc/profile.

By the way, if you need to modify umask in several groups, you can use grep regular or relational expressions, such

Echo $ usergroup | grep-Q-e 'dev'-e 'qa'

The Q Parameter represents quiet and is not output.
The parameter in uppercase with-E is stronger, which is equivalent to egrep.

For example, the preceding statement can be written as Echo $ usergroup | grep-Q-e 'dev | QA'

Execution sequence of Logon shell configuration files
/Etc/profile -->/etc/profile. d/*. Sh --> ~ /. Bash_profile --> ~ /. Bashrc -->/etc/bashrc
We should put this setting at the end of the last executed file/etc/bashrc to prevent the setting from being overwritten (in fact, the/etc/bashrc file in Linux has a umask setting similar to that in the beginning ).
Note: It is not directly supported to control users' default read/write permissions on a directory. In practice, it is not necessary for the moment. If you have special needs, you can use crontab to set monitoring process timing for modification. It is also very easy.

2. Privileged identities of common users
OK. In the first part, we solve the problem of multi-person file sharing and reading, and the running server is now ready. Isn't it tomcat? Start Up. It is not as simple as imagined. During Tomcat running, log files will be written. At the beginning, the logs directory group was divided into Dev, but a series of different permission problems were encountered one after another. So let's think about it: instead of slightly modifying the permissions on the files involved in running tomcat, how can we temporarily change our identity? This is what we want to talk about sudo.
The sudo command is used by sudoer to perform the root operation. Sudoer configuration, which can be edited through mongodo.
Mongodo is actually the packaged version of VI/etc/sudoers. But the biggest benefit of using this command is that it has syntax check.

% Dev all = nopassword:/usr/local/tomcat/bin/startup. Sh
% Dev all = nopassword:/usr/local/tomcat/bin/shutdown. Sh

% Dev all = nopassword:/usr/bin/RM/usr/local/tomcat/work/* (note that Rm must be in the full path)

Percent sign indicates a group. If multiple groups exist, use % Dev, % dev2
All is for all hosts. If you want to specify a host, you can change it to an IP address.
Nopassword indicates that the password does not need to be entered by sudoer.
Finally, it is the full path of the command to be authorized for execution.
There are many other sudoer configurations, such as setting aliases. Please learn them by yourself.
Execute: The team members only need to add sudo before the original command.

In this way, the problem of Tomcat shutdown is also solved.
Supplement:If all commands in a directory can be opened to sudoers, you can use xxxx/*. Sh. In this case, the user must use the absolute path for execution. The./xxx. Sh cannot be used in the current path. Why.
Iii. umask settings for SFTP users
Everything seems to be fine. But one day, I found that some files do not have the permission to overwrite them. Why? Later, we found that all these files were uploaded using winscp.
Solution:
In the VI/etc/ssh/sshd_config file, locate the subsystem SFTP/usr/libexec/OpenSSH/SFTP-server line and change it
Subsystem SFTP/usr/libexec/OpenSSH/sftp-server.sh
Then VI/usr/libexec/OpenSSH/sftp-server.sh
Add
Umask 0002
/Usr/libexec/OpenSSH/SFTP-Server
Chmod 755/usr/libexec/OpenSSH/sftp-server.sh.
Of course, this line of umask 0002 can be consistent with the above policy.
Change
Usergroup = '/usr/bin/ID-GN $ user'
Echo $ usergroup | grep-Q developers
If [$? -EQ 0]; then
Umask 0002
Fi

Iv. NFS File Settings
A and B are two servers. A is an NFS server and B is a mounted server. During development, it is found that this directory is always prone to permission issues. However, it is okay to check the group owner. It's strange.
Example:
An NFS Source Path, such as Hosta:/share. The directory on Hosta belongs to the user group Dev, and hostb mounts the directory. the user group in this directory is a group number, such as 105, it is actually the dev user group number on Hosta. But this group number does not exist on hostb (there is also a Dev group on hostb). How can users on hostb read and write the directory? Finally, we finally found out the crux of the problem: the group numbers on both sides are inconsistent, and the owner and group owner of the file, in essence, do not recognize the name of the ID. The modified side will make the other side unable to be written, resulting in a conflict.
Solution:Change the group numbers on both sides to the same one.
1. First, ensure that there is no 105 group on hostb. If there is one, you need to coordinate a group number that does not conflict with each other. You may need to modify the group numbers on both sides.
2. After the group number is determined, let's say 105. Run groupmod-G 105 Dev on hostb. You can view the changes through/etc/group.
3. Reset the group owner of the files involved in the reorganization.
4. Users in this group must log on again to take effect.

5. root user behavior restrictions

There are also root abuse issues. If you use root to compile and deploy the files generated by root, the dev user has no access permission. That is to say, since the group directory has been divided, each user should be a member of the dev group. The root user should switch to another user only when the user is authorized or cannot solve the problem.