NFS user identity mapping services

NFS (Network File System, Network File System) is a network within the enterprise more widely used file-sharing service, mainly used for file sharing between Linux and UNIX-like systems. It uses C / S mode, in a directory on the NFS server to share the directory, then the client can use this directory to mount local use. NFS service born in the 1980s, although the use of the system in CentOS7.6 NFSv4 is the latest version, but the NFS service itself is relatively simple, especially in terms of permissions function is relatively weak, so inappropriate if NFS service settings , it will have a more serious security risks in the enterprise network. In this paper, user identity mapping problem NFS service were analyzed, and the recommended configuration and usage. Paper prepared Linux virtual machines to build two experimental environment, the operating system version of the virtual machine used to CentOS7.6. In which the virtual machine is named Server IP address 192.168.80.10, called Client virtual IP address is 192.168.80.101.

Basic Configuration 1. NFS of

NFS default CentOS7 service system has been installed, but not running, so you first need to perform "systemctl start nfs" command to start the service Server in a virtual machine, and then execute "systemctl enable nfs" command to set the service to run automatically boot.
On the server side to create a new / var / share directory, and create a test in which the file test.txt.

[root@server ~]# mkdir /var/share
[root@server ~]# echo 'hello,world!' > /var/share/test.txt

Below / var / share directory to NFS shares and allows all clients to access.
The main configuration file NFS service is / etc / exports, in the / etc / exports file, each line defines a shared directory. Vi editor using open configuration file / etc / exports, wherein an increase in the following line:

[root@server ~]# vim /etc/exports
/var/share  *(ro,sync)

In the setting item, "/ var / share" represents the directory to share, "" indicates that all clients can access the shared directory options "ro" for permissions defined client is read-only (read-only), option "sync" represents the synchronous mode is enabled, the data in memory can be written to disk in real time.
After changing the configuration file, restart the NFS service to take effect.
[root@server ~]# systemctl restart nfs
Then the client can mount the shared directory to local use.

[root@client ~]# mkdir /mnt/nfs                                 #创建挂载点目录
[root@client ~]# mount -t nfs 192.168.80.10:/common /mnt/nfs        #挂载共享目录
[root@client ~]# ls /mnt/nfs                                    #查看共享目录中的文件
test.txt

Because NFS service itself does not have the user authentication function, and only supports authentication based on the client IP. In other words, when we set permissions for NFS service, not to assign rights for users and assign permissions only for the client IP. So if you want the IP address of 192.168.80.101 clients can perform a write operation to the shared directory, you can be on the server side configuration file as follows to modify, add IP client, and set permissions option "rw (read-write) ":

[root@server ~]# vim /etc/exports
/var/share  *(ro,sync)   192.168.80.101(rw,sync)

After editing, you need to restart the NFS service to take effect. But if the NFS share is being used by some servers, then just restart the NFS service is not allowed, it provides exportfs command in CentOS system, you can, without restarting the NFS service, reload / etc / exports file, so that the new settings to take effect. exportfs command common options are: -a (all mount or uninstalled), - r (remount), - v (show details) are usually a combination of these three options. By following exportfs command allows us to just set to take effect.

[root@server ~]# exportfs -arv
exporting 192.168.80.101:/var/share
exporting *:/var/share

First shared directory on the client uninstall, and then remount, so that server side settings to take effect. But it failed in the shared directory write test.

[root@Client ~]# umount /mnt/share                          #卸载共享目录
[root@Client ~]# mount 192.168.80.10:/var/share /mnt/share      #重新挂载共享目录
[root@Client ~]# touch /mnt/share/a.txt                     #写入测试失败
touch: 无法创建"/mnt/share/a.txt": 只读文件系统

This is because, although the server configuration file / etc / exports provided allowing a user to have access to / var / share directory, but the operating system level, the user / var / share directory does not have write access. To do so write to the shared directory, we must ensure that all have write permissions in NFS services and operating systems can only be two levels.
How to make the client may have write access to the shared directory at the operating system level, which would involve the user identity mapping problem.

2. The principle of user identity mapping

Although NFS service does not have the user authentication function, but NFS identity mapping provides a mechanism to manage user identities. When a client access NFS service, the server according to the situation of the identity of the client user mapped to NFS anonymous user nfsnobody. nfsnobody is a program by the NFS service user account is automatically created in the system, the account can not be used to log system, specially as the anonymous user account NFS services.

 [root@Server ~]# grep nfsnobody /etc/passwd        #查看nfsnobody用户的信息。
nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin

The so-called user identity mapping, refers to when the client access to the NFS server, the user will automatically be considered nfsnobody server, and set to perform operations in accordance with the user's permission. But not all clients are mapped to the nfsnobody user, provides the following options in the / etc / exports configuration file to determine whether the NFS client mapped nfsnobody users:

  • root_squash, when the NFS client access to the root user, the user is mapped nfsnobody NFS server.
  • no_root_squash, when the NFS client access as root, the root user is mapped to the NFS server, which is to be reserved for the super-user privileges. This option will leave a serious security risk, it is generally not recommended.
  • all_squash, no matter what NFS clients to access user identities are mapped to user nfsnobody NFS server.
    Where the default value is root_squash, that is, when the client access to NFS share as the root user, the server will automatically mapped to the anonymous account nfsnobody.
    The following points will be described several cases respectively.

    3. root user identity mapping

    The reason why we can not be written before operating on the client side, because the user has not given nfsnobody at the system level have write access to the shared directory / var / share. Here nfsnobody given permission by setting user rwx ACL rule.
    `[root @ Server ~] # setfacl -mu: nfsnobody: rwx / var / share``
    then the client remount the shared directory, and test whether written.

    [root@Client ~]# umount /mnt/share
    [root@Client ~]# mount -t nfs 192.168.80.10:/var/share /mnt/share
    [root@Client ~]# touch /mnt/share/b.txt

    At this point you can see the client can write, and the owner of a file is created it is nfsnobody.

    [root@Client ~]# ll /mnt/share/b.txt
    -rw-r--r--. 1 nfsnobody nfsnobody 0 3月  21 07:39 /mnt/share/b.txt

    Since the client user identity currently used is root, by default, when the Client Access NFS server, the server will be mapped to user identity that nfsnobody, so the server side as long as the user has given nfsnobody write to the shared directory permissions, then the client will naturally be written.
    Here we verify no_root_squash settings, that is not the root user identity mapping.
    First, modify the configuration file / etc / exports on the server side, add no_root_squash option / var / share shared directory.

    [root@server ~]# vim /etc/exports           #修改配置文件
    /var/share *(rw,no_root_squash,sync)
    [root@Server ~]# exportfs  -arv             #重新加载服务
    exporting *:/var/share

    Then remove the ACL rule on a shared directory / var / share the set, cancel nfsnobody write access to users of the directory.
    [root@Server ~]# setfacl -b /var/share
    Finally, the client remount the shared directory, and test whether written.

    [root@Client ~]# umount /mnt/share
    [root@Client ~]# mount -t nfs 192.168.80.10:/var/share /mnt/share
    [root@Client ~]# touch /mnt/share/c.txt
    [root@Client ~]# ll /mnt/share/c.txt 
    -rw-r--r--. 1 root root 0 4月  14 17:08 /mnt/share/c.txt

    Can be found, then the client can still be written. Because for NFS server, client access to the shared directory of the end user is the root server, with full rights to the shared directory. So no_root_squash option will have a great security risk, under normal circumstances is not recommended.

    4. The normal user identity mapping

    If the user identity used by the client is not root, but an ordinary user, then by default on the server side will see it as another user (other). Here the client continue to be tested as a normal user.
    First modify the server configuration file / etc / exports, the shared directory / var / share in no_root_squash option to remove, and then reload the service, again giving nfsnobody user read and write permissions to perform the way by setting the ACL rule.

    [root@server ~]# vim /etc/exports       #修改配置文件
    /var/share *(rw,sync)
    [root@Server ~]# exportfs  -arv         #重新加载服务
    exporting *:/var/share
    #通过设置ACL赋予nfsnobody用户rwx权限
    [root@Server ~]# setfacl -m u:nfsnobody:rwx /var/share

    Remount the client share, and the test can be written as root properly.

    [root@Client ~]# umount /mnt/share
    [root@Client ~]# mount 192.168.80.10:/var/share /mnt/share
    [root@Client ~]# touch /mnt/share/d.txt
    [root@Client ~]# ll /mnt/share/d.txt 
    -rw-r--r--. 1 nfsnobody nfsnobody 0 4月  14 17:29 /mnt/share/d.txt

    The following create a admin user on the client, and set a password.

    [root@Client ~]# useradd admin
    [root@Client ~]# echo 123 | passwd --stdin admin

    Switch to the admin user, attempt to write files to a shared directory, write failure, but the contents of the directory can be read. Therefore, if the client is a regular user access NFS shares, then by default on the server side is not to be mapped to nfsnobody, but treated as other users (other).

    [root@Client ~]# su - admin
    [admin@Client ~]$ touch /mnt/share/e.txt
    touch: 无法创建"/mnt/share/e.txt": 权限不够
    [admin@Client ~]$ cat /mnt/share/e.txt

    The following continue to modify the server configuration file / etc / exports, adding "all_squash" option in the sharing settings, all client users are mapped to nfsnobody.

    [root@server ~]# vim /etc/exports           #修改配置文件
    /var/share *(rw,sync,all_squash)
    [root@Server ~]# exportfs  -arv             #重新加载服务
    exporting *:/var/share

    And then remount the shared client again (the specific operation is omitted), this time as the admin user can write, and create files and can be found in the owner is also nfsnobody.

    [admin@Client ~]$ touch /mnt/share/e.txt
    [admin@Client ~]$ ll /mnt/share/e.txt 
    -rw-rw-r--. 1 nfsnobody nfsnobody 0 4月  14 17:37 /mnt/share/e.txt

    The user identity overlap

    In the process of using NFS sharing, and sometimes the user might encounter the problem of overlapping identities. The so-called user identity overlap, refers to the NFS service using the default setting (User Identity Mapping option root_squash), if given to a user on the server with the appropriate permissions to the shared directory, and the client happens to also have a users with the same uid , then when the client access to the shared user, the server will automatically have the corresponding user privileges. The following examples will be described.
    First, the server / var / share shared revert to the default setting, and the cancellation / var / share directory nfsnobody ACL rules for users, particularly the operation thereof is omitted.
    Assumed that there are a server user account name of the teacher, UID 1246, sets the user to the owner of the shared directory.

    [root@Server ~]# id teacher                 #查看teacher用户的身份信息`
    uid=1246(teacher) gid=1246(teacher) 组=1246(teacher
    #将teacher用户设置为/var/share目录的所有者
    [root@Server ~]# chown teacher /var/share
    [root@Server ~]# ll -d /var/share
    drwxr-xr-x. 2 teacher root 45 4月  14 17:37 /var/share

    The following operating at the client. First still remount the shared directory, and then the original admin user uid was changed to 1246.

    [root@Client ~]# usermod -u 1246 admin
    [root@Client ~]# id admin
    uid=1246(admin) gid=1002(admin) 组=1002(admin)

    Then the owner of the admin user can perform tests on the shared directory write operations, it can be found written normally, and the created file is admin.

    [root@Client ~]# su - admin
    [admin@Client ~]$ touch /mnt/share/f.txt
    [admin@Client ~]$ ll /mnt/share/f.txt
    -rw-rw-r--. 1 admin admin 0 4月  14 17:47 /mnt/share/f.txt

    On the server side admin view files created by the user, it is found that the owner of the teacher.

    [root@Server ~]# ll /var/share/f.txt 
    -rw-rw-r--. 1 teacher 1002 0 4月  14 17:47 /var/share/f.txt

    This is because for Linux systems, to distinguish between different uniquely identifies the user is uid, user name for convenience only as for humans to understand. So at the system level, both the teacher admin user or users, as long as their uid, that it is the same user. But it is precisely for this reason, it will lead to the identity of the user overlap problems, for NFS service, which is a serious security risk.
    How to avoid overlapping user identity it? Available from the following two aspects:

  • First, when you set up an NFS share recommended "all_squash" option, all client users are mapped to nfsnobody. This can effectively avoid the problem of overlapping user's identity.
  • Second, the system should be strictly controlled NFS shared directory permissions, try not to give permission for the average user.

Guess you like

Origin blog.51cto.com/yttitan/2406403