Issue regarding directories with 0600 permissions in strict snap

snapd
1

I’m trying to create a strict snap of https://github.com/aws/amazon-ssm-agent to run on ubuntu core 20

The code creates a lot of directories with permission 0600, and if amazon-ssm-agent is just running as root on ubuntu 20.04 everything works fine, however within a strict snap (with some code patching to set directory paths, etc) there are a lot of errors similar to

ERROR Registration failed due to Unable to save registration information. Failed to store instance info in vault. Failed to create vault folder. failed to create directory /var/snap/ecs-anywhere/current/var/lib/amazon/ssm/Vault/Store. mkdir /var/snap/ecs-anywhere/current/var/lib/amazon/ssm/Vault/Store: permission denied

root@ubuntu:/var/snap/ecs-anywhere/current/var/lib/amazon/ssm# ls -la
total 12
drwxr-xr-x 3 root root 4096 Jun  9 11:54 .
drwxr-xr-x 3 root root 4096 Jun  9 11:52 ..
drw------- 2 root root 4096 Jun  9 11:54 Vault

stuart-warren@ubuntu:~$ sudo snap run --shell ecs-anywhere.amazon-ssm-agent
root@ubuntu:/home/stuart-warren# mkdir /var/snap/ecs-anywhere/current/var/lib/amazon/ssm/Vault/foo
mkdir: cannot create directory ‘/var/snap/ecs-anywhere/current/var/lib/amazon/ssm/Vault/foo’: Permission denied

Yet outside of the context of the snap I can create that directory

stuart-warren@ubuntu:~$ sudo mkdir /var/snap/ecs-anywhere/current/var/lib/amazon/ssm/Vault/foo
stuart-warren@ubuntu:~$ sudo ls -l /var/snap/ecs-anywhere/current/var/lib/amazon/ssm/Vault
total 4
drwxr-xr-x 2 root root 4096 Jun  9 12:00 foo

I’m just trying to understand what the issue is and how I can get around it

A simple way to reproduce it:

stuart-warren@ubuntu:~$ snap install hello-world
hello-world 6.4 from Canonical✓ installed
stuart-warren@ubuntu:~$ sudo snap run --shell hello-world
root@ubuntu:/home/stuart-warren# mkdir -p ${SNAP_DATA}/foo
root@ubuntu:/home/stuart-warren# chmod 600 ${SNAP_DATA}/foo
root@ubuntu:/home/stuart-warren# mkdir -p ${SNAP_DATA}/foo/bar
mkdir: cannot create directory ‘/var/snap/hello-world/29/foo’: Permission deni
3

I finally worked this out!

It’s due to missing CAP_DAC_OVERRIDE for the root user within the snap (due to apparmor)

Adding the log-observe plug and connecting it gives it back, though there might be a cleaner way?

1 Like
4

This is unexpected, that capability should only be necessary if the group/owner do not match

5

This appears to be the expected behaviour for users without CAP_DAC_OVERRIDE (as root in the snap sandbox is):

$ mkdir foo
$ chmod 0600 foo
$ ls -ld foo
drw------- 2 james james 4096 Jun 10 11:40 foo
$ mkdir foo/bar
mkdir: cannot create directory ‘foo/bar’: Permission denied

The fix would be to change the code to add owner execute permission to the directory, or only remove the execute permission after creating the subdirectories.

Is there any indication why the app is creating directories that require DAC override to access? Given that the directory can only be accessed by root, it’s already inaccessible to other users.

6

sorry, I don’t see any obvious comments on those commits other than a link to some amazon internal code review tool. It seems to have been there for 5 years or so.

Assuming this situation won’t change, and patching those permissions at build time would be quite a bit of maintenance work, is there a better way to get the capability other than the log-observe plug?

7

I don’t think there is a better option to add just dac_override at present.

It might be worth filing a bug report with upstream explaining the problem you ran into, to see if there is a reason for what they’re doing. If there isn’t, perhaps it can be fixed.

With all that said, perhaps this is the kind of service where classic confinement would be appropriate. The purpose of the agent is to run arbitrary commands on a VM that is part of a larger cluster. It’s not clear any collection of interfaces is going to describe everything a user might want to use the tool for. We’ve granted classic confinement to other similar tools (e.g. slurm). This would have its own approval/vetting process, but might be the right option for something like this.