Ubuntu的OSX`chmod -h`标志是什么?


13

在OSX中,我可以设置符号链接本身的权限(而不是它指向使用-h的东西)。从手册页:

 -h      If the file is a symbolic link, change the mode of the link itself rather than the file that the link points to.

在Ubuntu 14.04中,我尝试设置符号链接的权限,但这仅在符号链接目标上设置。

它与从/home/nagios/.ssh/someprivatekey到的符号链接有关/somewhere/else/privatekey,因此权限对于ssh很重要。我该如何实现?


那么,为什么需要这个符号链接?
— 大师

1
您确定ssh关心符号链接上的权限,而不关心/ somewhere / else / privatekey上的权限吗?
— Random832

@ Random832是的,我可能得出了错误的结论,对于在ls -l输出(lrwxrwxrwx)中如何显示权限,我也有些困惑。
— Ray Burgemeestre,2015年

@muru我正在创建一个(buildserver)Docker映像,该映像使用ssh密钥来访问各种服务器。由于各种原因(例如,如果我想将其托管在docker hub上),我不想将私钥放入其中。因此,我对它进行了符号链接,并使其指向仅在映像运行后才挂载的卷。虽然,想起来了,我可能也改变了使用的关键位置.ssh/config:)
— 雷Burgemeestre

Answers:


18

不可能。因为符号链接的权限是没有意义的,所以没有办法(符号链接不是文件;它仅指向文件)。但是,使用Linux进行此操作的方法是通过ACL。

symlink被解释为...

未指定创建的符号链接的文件模式位的值。POSIX.1-2008指定的所有接口的行为都应像始终可以读取符号链接的内容一样,只是未指定stat结构的st_mode字段中返回的文件模式位的值。


区别在这里:chmod和chmod ...它是BSD与Linux。


不知道这是否重要,但是关于SSH:它使用 stat(2)而不是lstat(2)来获取权限。

  • stat()统计路径指向的文件并填充buf。
  • lstat()与stat()相同,不同之处在于,如果path是符号链接,则该链接本身是状态,而不是其引用的文件。

2
甚至在最新版本中都没有指定对符号链接设置权限的功能,它是BSD扩展。
— Random832

1
@ Random832嗯,可能更准确。我今天在SO上阅读了一下,但是没有对此进行检查:D
— Rinzwind

4
顺便说一句,POSIX确实指定了该fchmodat功能,该功能可用于更改符号链接的模式(可选功能-不支持该功能的系统,包括Linux,返回错误EOPNOTSUPP),但是chmod命令中没有任何使用该功能的功能。仅-R在POSIX中定义。
— Random832

2
symlink权限在Linux上毫无意义。在可以更改它们(使用lchmod(2)或fchmodat(2)...)的系统上,它们确实具有含义(允许/拒绝readlink()(读取)或通过它们的路径解析(执行))。由于您无法更改符号链接的目标,因此通常没有写权限。
— 斯特凡Chazelas

Unix会不同意“符号链接不是文件”的观点。符号链接是一个特殊文件。
— 霍布斯

9

你不能 底层chmod系统调用在Linux中根本不支持此功能,因此,Linux也不在乎链接的权限。来自man chmod:

chmod never changes the permissions of symbolic links; the chmod system
call cannot change their permissions.  This is not a problem since  the
permissions  of  symbolic  links  are  never  used.   However, for each
symbolic link listed on the command line, chmod changes the permissions
of  the  pointed-to  file.   In  contrast, chmod ignores symbolic links
encountered during recursive directory traversals.

至于硬链接或绑定挂载,则使用源的权限,因此在其他地方反映文件内容的三种标准方法都不能帮助您。


这个答案对我来说也很清楚,对不起,我只能接受一个答案!
— Ray Burgemeestre,2015年
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.