为什么从Linux挂载nfs共享需要使用特权端口?


11

我在Linux机器上导出目录,可以使用以下命令从另一个Linux机器上挂载它

# mount -t nfs kurush:/media/lynk /mnt/kurush/

在Mac OS X上,同一命令失败:

$ sudo mount -t nfs kurush:/media/lynk /Volumes/lynk
mount_nfs: can't mount /media/lynk from kurush onto /Volumes/lynk: Operation not permitted

同时,kurush:/var/logs/syslog记录以下行:

rpc.mountd[7943]: authenticated mount request from sds-MacBook-Pro.home:1009 for /media/lynk (/media/lynk)

当我尝试通过GUI(finder-> connect to server nfs://kurush/media/lynk- > -> connect)时,我立即失败(无法连接&c),并且linux box syslog记录了authenticated mount request

通过使用特权端口可以解决此问题

命令行:

sudo mount -o resvport -t nfs kurush:/media/lynk /Volumes/lynk

要启用GUI:

sudo vifs

然后添加一行

kurush:/media/lynk /Volumes/lynk nfs resvport,ro,user,noauto

问题是

  • 为什么需要使用特权端口?我在linux方面做这件事吗?我似乎还记得,曾几何时,我确实在没有上述魔术的情况下安装了该共享。

  • 如何告诉MacOSX使用特权端口而不使用命令行?我以为苹果适合“非技术人员”人群,所以一定有可能!


你好 通常,我们会关闭询问“ Apple为什么要使用X?”的问题。但是这里有一些不错的技术细节。如果您只问问题(编辑下来),然后将所有答案放在答案部分,则您的问题可能会更好。如果您需要提出后续问题以解释问题所在,也许可以解决。您最终将如何处理Apple为什么如此设计的故事?
bmike

1
@bmike:我将“为什么”更改为“如何”。
2014年

Answers:


10

你为什么要 传统,主要是。曾几何时,将NFS限制为特权端口(<1023)被认为是一种安全措施。回到人们使用大型计算机时,这可以确保客户端上的NFS软件是OS的一部分/由管理员批准,因为程序只有在由root用户运行的情况下才能使用特权端口。如今,这已经没有意义了,因为任何人都可以拥有一台计算机并具有root用户访问权限,因此,从安全性上讲,这没有任何意义。

默认情况下,许多NFS服务器不允许非特权源端口。除非另外指定,否则某些NFS客户端(例如Ubuntu)默认使用特权源端口,这就是Linux客户端正常工作的原因。显然,OS X客户端不会这样做。我不知道这是Apple设计的选择还是BSD继承的东西。我知道Solaris也默认使用非特权端口。

避免此问题的两种方法是,如发现的那样,告诉OS X客户端使用特权端口,或者将NFS服务器配置为允许非特权端口(在服务器的文档中查找)。

如何使OS X通过GUI使用特权端口?据我所知,您无法使用版本> 10.6。一种曾经能够在“磁盘工具”中挂载NFS共享并键入额外的选项,但是该选项已被删除。(详细信息)这绝不是一个简单的按钮或其他任何东西。NFS几乎不是大多数“非技术性”人群所需的东西,因此我想这并不是优先事项,并且有理由定期使用特权端口不是一个好主意。

我没有尝试过,但是http://www.bresink.com/osx/NFSManager.html似乎允许配置OS X的NFS功能而无需命令行。


2
关于“或配置NFS服务器以允许非特权端口”:对于nfs-kernel-server,它是中的insecure选项/etc/exports。例如:/media/sda3 192.168.1.0/24(rw,async,no_subtree_check,insecure)
2015年

谢谢,不安全允许Mac使用
Finder-

对于当今的系统来说,这是一个积极的安全问题,通常是在Intranet中而不是Internet上。由于系统倾向于在文件系统中挂载NFS共享,因此存在很大的滥用空间。仍然需要特权端口仍使用户无法操纵文件系统。当然,如果用户已经具有root用户,那就没关系了。
jtpereyda
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.