开始新对话

此帖子已超过 5 年

Solved!

Go to Solution

4769

2014年8月20日 15:00

aix下mount点和mount后的文件系统权限问题

大家好,今天遇到一个问题,以前没注意过。root新建一个目录/home/test,umask是023,这个时候建立的目录属主是root,然后o的权限是r--,

然后新建一个文件系统挂载到/home/test上,然后更改文件系统的目录属主为另一个普通用户假设叫user,

这个时候切换到用户user,然后进入/home/test目录,此时文件系统已经挂载到/home/test

然后执行ls -ld /home/test正常显示,但是ls -ld ../就报不允许,然后发现目录下也没有..

详细情况如下图:

0.JPG.jpg

1.JPG.jpg

2.JPG.jpg

麻烦问下大家以下几个问题:

mount之后的目录的权限是什么决定的?

为什么mount之后ls -a没有..呢?

为什么ls -ld ..提示不允许?

这个挂载点的权限和实际挂载的文件系统的权限是什么关系?

这种问题如果在网上搜应该如何描述?我今天找了好久也不知道怎么描述能找到答案。。。

谢谢各位了



更新:上面的图片可能有些疑问的地方就是..指向的是/home我又做了个操作,请看下面的图片:

1.JPG.jpg

2.JPG.jpg

3.JPG.jpg


可见挂载前的目录是否对切换的普通用户之后具有x权限(就是o是否具有x),影响切换为user之后能否ls ..这个操作。这个是让我奇怪的地方。

上面操作是否能说挂载点目录(挂载之前)的权限和挂载后的文件系统的权限之间是有一定关系的,即使挂载之后,挂载前的挂载点目录也会对挂载后的某些操作有影响,因为..就失效了,是不是这个..去找的时候和直接全路径找的方式有不同?



再更新:搜索到一个帖子讲了一下这个事,Detecting and Fixing Underlying Mount Point Permission Errors on AIX (Brian Smith's AIX / UNIX / Linux / Open Source blo…但是仍然没有说下具体原理。然后博主提供了脚本可以在mount状态下更改这个问题。以免还要重新卸载文件系统。

1.2K 消息

2014年8月21日 18:00

报错的原因是切换成其他用户以后没有父目录的执行权限,x决定了用户能否cd到这个目录下。比如说,你对/home/user有执行权限,但是对/home没有,当前目录是/home/user,你可以通过相对路径访问/home/user下的文件,但不能通过绝对路径访问。

因此,不要把挂载点的权限设置的太受限,至少为 "r-xr-xr-x"。如果设成 "rwx------"作为其他用户list file操作时, AIX 就会对 parent directory显示奇怪的信息,如下所示:

# ls -ald /app1 ##Mount point permissions/owner prevent any users from even listing contents of directory
drwx------ 2 root system 256 Sep 04 19:05 /app1
# mount /app1 ##Mount the File System
#
# su - brian ##Switch to a unpriveleged user
$
$ ls -ald /app1 ##Since the filessytem is mounted the filesystem permission, owner, and group have taken affect
drwxr-xr-x 3 app01 appgrp01 256 Sep 04 19:04 /app1
$ cd /app1
$ ls -al
ls: 0653-345 ./..: Permission denied. ##This is happening because our mount point permissions are too restrictive
total 0
drwxr-xr-x 3 app01 appgrp01 256 Sep 04 19:04 .
drwxr-xr-x 2 root system 256 Sep 04 19:04 lost+found
$
$ ls -al ..
ls: 0653-345 ..: Permission denied. ##This is happening because our mount point permissions are too restrictive
$

这一篇文章也有提到这个问题:Managing filessytem mount point permissions

109 消息

2014年8月20日 16:00

这个和新mount的文件系统应该没关系,而是和 /home 目录的权限有关。

下面是一个简单的重现 (Linux):

root / #su - alex

~$ ls ..

alex

~$ logout

root / #

root / #

root / #su - alex

~$ pwd

/home/alex

~$ ls ..

alex

~$ exit

logout

root / #chmod 023 /home

root / #su - alex

~$ ls ..

ls: cannot open directory ..: Permission denied

~$ exit

logout

root / #chmod 755 /home

root / #su - alex

~$ ls ..

alex

~$ exit

logout

4 消息

2014年8月21日 03:00

你好,我又更新了下我的操作,麻烦您再给看下,新的是我的疑问,谢谢。

4 消息

2014年8月22日 16:00

恩,谢谢,我也看了那篇文章,我觉得关键是以前一直觉得挂载后只看挂载后文件系统根目录的权限就行了,没想到aix中即使在挂载后挂载点权限也会对某些操作有奇怪的影响。这个问题是我们在应用用户目录下进行tuxedo的tmloadcf时候发现的报错。中间件的同事说这个和不同操作系统的stat函数实现有关。至于操作系统内部到底是如何实现的估计是不好知道这件事了。

实际上通过前面我贴图的第二部分操作可以看到user用户对home是有x权限的,但是因为挂载点目录无x导致报了上述奇怪的错误,但是此时文件系统已经挂载了,且文件系统挂载后的目录对于user来说是有x权限的,所以我就觉得很奇怪,感觉操作系统中去找..的时候应该是通过./../的路径或者其他方式读取了挂载点的目录权限,和直接通过绝对路径方式/home这样找是不一样的。

1.2K 消息

2014年8月25日 01:00

这个问题应该是隐含在syscall statx()的  EACCES return code,这一段代码的定义描述如下:

Capture.PNG.png

“searchable”在UNIX里面也就是“+x”,所以为了让system call能够查找,对目录必须要有“x”权限。

AIX查找..的时候会去查找挂隐含在文件系统之下挂载点目录的..,而作为user对于挂载点目录没有这一权限进行遍历。解决方法就是在mount文件系统之前把挂载点目录的权限设置的高一些。

找不到事件!

Top