Cannot open path of the current working directory: Permission denied

snapd
1

When I run a user command exposed as an app by our slurm snap I get the error cannot open path of the current working directory: Permission denied. When I run the wrapper directly it succeeds.

jbemfv@juju-04b40a-0:~$ slurm.sinfo
cannot open path of the current working directory: Permission denied

jbemfv@juju-04b40a-0:~$ /snap/slurm/current/slurm-bins/sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST 
debug*       up   infinite      1   idle juju-04b40a-0

Listing the cwd shows that the execute bit is disabled for other.

jbemfv@juju-04b40a-0:~$ ls -la
total 288
drwxr-sr-- 5 jbemfv scaniausers 127 Jun 11 18:08 .
drwxr-xr-x 3 root   root          0 Jun 11 17:24 ..
-rw------- 1 jbemfv scaniausers 937 Jun 11 18:01 .bash_history
drwx--S--- 2 jbemfv scaniausers  38 Jun 11 14:46 .cache
drwx--S--- 3 jbemfv scaniausers  35 Jun 11 14:46 .gnupg
-rw------- 1 jbemfv scaniausers 808 Jun 11 18:08 .viminfo
drwxr-sr-x 3 jbemfv scaniausers  23 Jun 11 14:51 snap

If I make a new directory, cd into it and try running the snap.sinfo command it succeeds.

jbemfv@juju-04b40a-0:~$ mkdir snap_exec_test

jbemfv@juju-04b40a-0:~$ cd !$
cd snap_exec_test

jbemfv@juju-04b40a-0:~/snap_exec_test$ slurm.sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST 
debug*       up   infinite      1   idle juju-04b40a-0 

jbemfv@juju-04b40a-0:~/snap_exec_test$ ls -la
total 80
drwxr-sr-x 2 jbemfv scaniausers   0 Jun 11 18:17 .
drwxr-sr-- 6 jbemfv scaniausers 159 Jun 11 18:17 ..

I feel like the execute bit being disabled on the user home is what is causing this, but then why would running the wrapper directly work?

A bit confused, any ideas here?

Thanks!

1 Like
2

Without knowing more about how Snapd operates user commands, I’m guessing that the command is actually invoked by Snap itself either as root or as some kind of snapd user which is considered an “other” user and not allowed since that bit is not flipped.

Its worth noting that this issue should manifest itself in NFS mounts also, since permissions are handled differently and the system’s “root” user would be considered an “other” user despite being root itself.