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
$ 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?

  • what does df -T . say? – greggo Jan 19 '15 at 21:59
  • 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. – rhymes_with_dorange Jan 19 '15 at 23:09
  • OK, so it appears that the usual linux permissions don't apply in AFS, even though 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 with fs la directory_name. Once I knew that this had to do with AFS, I was able to find this helpful link. – rhymes_with_dorange Jan 19 '15 at 23:44
  • @greggo, would you like to submit an answer to this question? – rhymes_with_dorange Jan 19 '15 at 23:45
  • @rhymes-with-dorange I don't have an answer; I just thought that knowing the filesystem would be important - since I've not seen this behaviour with the FS's I've had experience with. Thanks for editing the question to specify it's AFS. – greggo Jan 20 '15 at 14:14

AFS does not use traditional Unix permissions (though it does remember them), nor POSIX ACLs (what you see with getfacl). There are some exceptions with Unix permissions (if you remove all access to read or write with chmod, I believe that does remove the relevant access for everyone), but generally speaking AFS uses its own ACL system.

Assuming you are using OpenAFS, to see the permissions on a file or directory, run fs listacl <path>. To set the permissions, if you have access, run fs setacl <path> <user> <perms>. The permissions granted by AFS ACLs are different from both Unix chmod-style permissions, POSIX ACLs, and, well, any other access system I'm aware of. They are explained in detail here, but briefly: you have 7 permissions, usually represented by a single letter. They are: 'r'ead, 'l'ist, 'w'rite, 'i'nsert, 'd'elete, loc'k', and 'a'dmin.

So for example, a directory you can look at and read files in would look like this:

$ fs listacl somedir
Access list for somedir is
Normal rights:
   system:anyuser rl
   system:administrators rlidwka

Which means that 'system:anyuser' (anybody in the world) can only 'l' the directory contents, and 'r'ead the contents of files in that dir. On the other hand, 'system:administrators' (a group used for admin users) can do anything.

A directory that you cannot access might look like this:

$ fs listacl privdir
Access list for privdir is
Normal rights:
   system:administrators rlidwka
   foouser rlidwka

Which means that only administators and 'foouser' can do anything to that directory. However, if you can't access a directory at all, I think you also won't be able to fs listacl it, so that will show an error message instead.

If you're not using OpenAFS, but are instead using the AFS implementation in the upstream Linux source tree ("kAFS"), then you won't have the fs command. I don't believe it's possible to view AFS ACLs with that implementation, but I could be wrong about that.


Access Control Lists can do that. Did you check your username and groups in the bash session? whoami and groups

  • Yes, I checked the username and groups and they were what I expected. The output in getfacl private shows that there aren't any ACLs here, right? – rhymes_with_dorange Jan 19 '15 at 23:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.