Linux: NFS

[lihongjie0209]

网络文件系统（英语：Network File System，缩写作 NFS）是一种分布式文件系统，力求客户端主机可以访问服务器端文件，并且其过程与访问本地存储时一样，它由太阳微系统（已被甲骨文公司收购）开发，于1984年发布[1]。

它基于开放网络运算远程过程调用（ONC RPC）系统：一个开放、标准的RFC系统，任何人或组织都可以依据标准实现它。

假设一个Unix风格的场景，其中一台计算机（客户端）需要访问存储在其他机器上的数据（NFS 服务器）：

1. 服务端实现 NFS 守护进程，默认运行 nfsd，用来使得数据可以被客户端访问。
2. 服务端系统管理员可以决定哪些资源可以被访问，导出目录的名字和参数，通常使用 /etc/exports 配置文件 和 exportfs 命令。
3. 服务端安全-管理员保证它可以组织和认证合法的客户端。
4. 服务端网络配置保证可以跟客户端透过防火墙进行协商。
5. 客户端请求导出的数据，通常调用一个 mount 命令。 如果一切顺利，客户端的用户就可以通过已经挂载的文件系统查看和访问服务端的文件了。 提醒：NFS自动挂载可以通过—可能是 /etc/fstab 或者自动安装管理进程。

[lihongjie0209]

服务端配置

yum install -y nfs-utils

systemctl enable nfs --now

配置可以挂载的目录

[root@localhost mysql]# cat /etc/exports
/data/mysql *(rw)

目录  主机(参数)

[lihongjie0209]

客户端配置

挂载到本地文件夹

mount.nfs 192.168.2.20:/data/mysql/ /data/mysql/

尝试写入

[root@linux1 mysql]# touch a.txt
touch: cannot touch ‘a.txt’: Permission denied

权限配置

我们需要理解NFS写入的过程

首先客户端创建的时候会检查本地的文件夹权限， 也就是 /data/mysql/ 我们现在是root用户， 所以本地权限没有问题

然后客户端通过远程调用写入 192.168.2.20：/data/mysql, 这个时候我们就需要考虑了写入的时候写入进程的uid是多少。

显然我们客户端和服务端不可能共享用户信息（uid）， 那么一个rpc请求过来创建的文件属于谁的呢？？

一般来说假如用户 test 创建了一个文件， 那么我们希望这个文件属于 test 用户

[root@linux1 /]# useradd test

[root@linux1 mysql]# sudo -u test touch test.txt 

[root@linux1 mysql]# ll
total 0
-rw-r--r--. 1 root root 0 Jul 20 22:45 localhost.localdomain
-rw-r--r--. 1 test test 0 Jul 20 23:20 test.txt

我们去服务端看看

[root@localhost mysql]# ll -h
total 0
-rw-r--r--. 1 root root 0 Jul 20 22:45 localhost.localdomain
-rw-r--r--. 1 1000 1000 0 Jul 20 23:20 test.txt

然后我们再看看test用户的uid

[root@linux1 mysql]# id test
uid=1000(test) gid=1000(test) groups=1000(test)
[root@linux1 mysql]# id root
uid=0(root) gid=0(root) groups=0(root)

我们发现， 默认情况下nfs会按照客户端的uid创建文件， 这样会导致两个问题

root 用户

root用户的UID所有的系统都是0， 也就是说 root@host1 创建的文件和 root@host2 创建的文件都是属于 uid=0， 那么大家就无法区分了， 而且这样做也不安全。

uid重复

假如 zhangsan@host1 uid = 1000 lisi@host2 uid = 1000

创建的文件都是uid=1000， 那么在客户端看来zhangsan可以操作lisi的文件

nfs配置uid map

By default, exportfs chooses a uid and gid of 65534 for squashed access. These values can also be overridden by the anonuid and anongid options. Finally, you can map all user requests to the anonymous uid by specifying the all_squash option.

Here's the complete list of mapping options:

root_squash Map requests from uid/gid 0 to the anonymous uid/gid. Note that this does not apply to any other uids or gids that might be equally sensitive, such as user bin or group staff. no_root_squash Turn off root squashing. This option is mainly useful for diskless clients. all_squash Map all uids and gids to the anonymous user. Useful for NFS-exported public FTP directories, news spool directories, etc. The opposite option is no_all_squash, which is the default setting. anonuid and anongid These options explicitly set the uid and gid of the anonymous account. This option is primarily useful for PC/NFS clients, where you might want all requests appear to be from one user. As an example, consider the export entry for /home/joe in the example section below, which maps all requests to uid 150 (which is supposedly that of user joe).