7

I'm using a Chromebook and would like to navigate inside the Android container via the shell. The container is mounted at the path /run/containers/android_XXXXX. When trying to cd into the directory, I'm told Permission Denied. I've tried running the command as sudo, but for some reason the cd command becomes inaccessible. I've ran chmod u+x on the directory, but no dice.

What steps can I take from here?

I've ran stat on the directory, which returns the following:

 File: ‘android_XXXXXX/’ Size: 80 Blocks: 0 IO Block: 4096 directory Device: fh/15d Inode: 59640 Links: 3 Access: (0700/drwx------) Uid: (655360/ UNKNOWN) Gid: (655360/ UNKNOWN) Context: u:object_r:tmpfs:s0 Access: 2016-10-31 04:04:52.680000040 +0000 Modify: 2016-10-31 04:04:52.200000040 +0000 Change: 2016-10-31 04:44:54.990001186 +0000 Birth: -
Improve this question
1
  • Since you're talking about a permission problem, where is your whoami and the permission listing for the directory in question? Commented Oct 31, 2016 at 5:01

2 Answers 2

Reset to default
14

The directory is drwx------ so only someone whose uid is 655350 (which is not listed in the password file) can read it or enter it.

sudo cd not being able to find the cd command is expected, it is a builtin to the shell. If it wasn't builtin then it wouldn't work. Say your current shell has a process ID of 54000, you ran the /bin/cd command, it might be PID 54309. It would change the directory for process 54309, and then exit. process 54000 would still be in its original directory.

chmod u+x alters user (owner) permission.

What you want is sudo chmod go+rx /run/containers/android_XXXXX

Improve this answer
3
  • Worked like a charm, thank you. I haven't ever seen the 'go' parameter before. Thanks for clarifying the behaviour of PIDs in the shell. Commented Oct 31, 2016 at 10:44
  • 4
    g is group and o is other, I was just changing them both at the same time. Almost certainly I could have used o+rx Commented Oct 31, 2016 at 10:54
  • 1
    Ah, I've got you. That's certainly useful to know! Commented Oct 31, 2016 at 10:55
2

In addition to checking permissions like @icarus mentioned, you also need to check your ACLs (Access Control Lists) with getfacl to make sure that there aren't any rules overriding the basic file access privelages.

NOTE: If getfacl doesn't exist on your system, them it probably isn't the issue.

Example ACL that shouldn't be an issue.

$ getfacl test/ 
# file: test/ # owner: root # group: root user::rwx group::r-x other::r-x

This indicates that there are no additional ACL rules applied, other then the standard POSIX access rules. You can see that it matches the output of ls -ald in terms of permissions. (The -d argument to ls tells it to show you the directory itself, not its contents.)

$ ls -ald test/ 
drwxr-xr-x 2 root root 4096 May 8 19:11 test/

Example of a ACL that could cause you issues.

$ getfacl test/ 
# file: test/ # owner: root # group: root user::rwx user:mc:r-- group::r-x mask::r-x other::r-x 
$ ls -ald test/ 
drwxr-xr-x+ 2 root root 4096 May 8 19:11 test/

In this case, looking at the output of ls -ald, you wouldn't think there would be an issue. However, because ACL rules apply over POSIX rules, the user mc would be unable to change into the directory due to the lack of executable permissions for him, dispite the fact that the others permission set would otherwise give them to mc.

Something to note though, the owner permissions seem to take president over all other ACL rules, and I believe the same goes for the group owner permissions.

The Arch Wiki has more information about ACL's. Check out https://wiki.archlinux.org/title/Access_Control_Lists if you are intersted in learning more about them.

Understandably, you may not want to always check getfacl to see if that is your issue, or you may forget to do so. Fortunately, ls -al does tell you when there are additional ACL rules applied. If you take a look at the output of ls -al, you can see a + at the end of the list of permission bits whenever there are ACL rules applied, and it does not show otherwise (at least that appers to be the case in my short testing).

TLDR: If you see a + in the permissions list from ls -al, check the Access Control List (getfacl).

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.