I've encountered some unexpected behavior when trying to access directories in an AFS mount using Linux (specifically, in bash 4.3.11(1)-release on Ubuntu 14.04.1). In some cases, I'm unable to access directories that I should be able to access, and in others I am able to access some directories where I have no permissions at all. For example:
$ ls -l
total 24
drwxr-xr-x 9 70296 root 6144 Jan 12 14:44 look_inside
drwx------ 278 someadmin operator 10240 Jan 17 17:54 private
<output truncated>
$ cd look_inside
-bash: cd: look_inside: Permission denied
$ ls look_inside
ls: cannot open directory look_inside: Permission denied
I am not the owner and I'm not in group root
, so the everyone permissions should apply to look_inside. Everyone has r-x
permissions for look_inside
and all its parent directories, and yet I'm unable to use cd look_inside
or ls look_inside
. On the other hand, I can access private
, even though I have no permissions:
$ getfacl private
# file: private
# owner: cbl
# group: operator
user::rwx
group::---
other::---
$ ls -l private
total 560
<output truncated>
I'm not the owner of private
, either. I am in group operator
, but that shouldn't matter since the group doesn't have any permissions for private
. And yet, I'm able to access private. That said, I can't access any of the directories inside it, whether or not I have r-x
permissions (see below). That makes sense, of course, because I don't have x permission on their parent. There are no regular files in private
(or at least, I'm only shown directories when I run ls
), so I don't know how regular files are affected.
$ cd private
$ ls -l
total 560
drwx------ 3 someadmin operator 2048 Jan 16 14:11 someuser
drwxr-xr-x 3 otheradmin operator 2048 Jan 16 14:11 otheruser
<output truncated>
$ ls -l someuser
ls: cannot open directory someuser: Permission denied
$ ls -l otheruser
ls: cannot open directory otheruser: Permission denied
What could be causing this behavior? Is there any way for me to access look_inside
? Should I (or the system's admin) be concerned that I'm able to access private
?
df -T .
say?df -T .
shows that the type is afs and that all blocks available (0% use). I didn't realize that it was relevant that this was AFS, but I'm guessing from your comment that it's important.ls -l
will happily display them. AFS has its own permissions system that only works at a directory scope. Information about a directory's permissions can be obtained withfs la directory_name
. Once I knew that this had to do with AFS, I was able to find this helpful link.