Examples
The same group microsoft
of two accounts and the justmine001
justmine002
need for co-ownership /microsoft/eshop
of the directory development Rights in order to work together, but others are not allowed to access and access to the directory.
From an example, we can analyze:
- Accounts under the same group need to have the right to use the directory together, and can edit any of the files inside.
- Other accounts do not have any permissions for this directory.
- Need to use
root
accounts, create accounts, groups, set directory permissions, and then build a development environment.
Create account-related information
groupadd microsoft ; 新增群组useradd -G microsoft justmine001; 新增账户,并加入到群组microsoftuseradd -G microsoft justmine002; 新增账户,并加入到群组microsoft
Check Account Properties
id justmine001;id justmine002;
Build environment Create a development directory
mkdir -p /microsoft/eshop
Inquire
ll -d /microsoft/eshop
Set legacy Permissions
As you can see, the owner and the group of the development catalog are root
, permissions are rwxr-xr-x
, so justmine001
and can look up justmine002
( ls
) and enter ( cd
) the directory, but none of the files are created in the directory.
First, set up the directory group for microsoft
, and second, the other person does not have any permissions on the directory, so you should set the permissions to 770. If you don't understand, please read the previous article on Linux document properties, owners, groups, permissions, differences
chgrp microsoft /microsoft/eshop; 分配群组chmod 770 /microsoft/eshop; 设置权限
First Test justmine
the permissions of the account (other person) as follows:
Other people are unable ls
to access and enter cd
the directory and have achieved the desired effect.
Test the same group justmine001
and the justmine002
account, create the file again, as follows:
For the most revealing, I intercepted the entire process of file creation permissions from rejection to licensing!!!
As can be seen from the above, the file test
and test1
the owner and group are respectively justmine001
and justmine002
, although the user justmine001
can delete the file test1
(the control scope of the directory permissions), but can not edit it (file Permissions control range). That should be swollen to do, or can not complete the collaborative work AH. Then we set the file permissions to 777 , so that the file for anyone can be read, writable, editable, plus the control of directory permissions, no, no problem. There is also a way to change the file groups they create microsoft
so that they can work together, which seems to be a realistic approach. However, every time the administrator to do this thing, it would be too much trouble he old, more embarrassed Ah, hey. It is so-called that there must be a way in front of the driveway, and we can use Linux
special permissions SGID
umask
to define this default behavior so that files created by any account under the same group can be modified with each other.
Note: The Linux document permissions are controlled at a level down, and read, write, and edit the file as long as it is accessible to the directory.
Set special Permissions
/microsoft/eshop
set permissions for a directory SGID
chmod 2770 /microsoft/eshop
Use justmine002
account to create files, query file permissions:
From can see, justmine002
belong to the file group automatically changed to microsoft
, and umask
by default 002
, two people belong to a group, nature can modify each other's files!!!
Summarize
For document multi-tenancy management, we'd better create a new unified group, then set the directory permissions to 2770
, and finally join the group of users who need to work together, it's that simple.
Share an example of a Linux management document multi-tenancy