Dac_override denied, in the Sia snap

snap
1

Hello,

I was using Sia to test the snapcraft release, and found an apparmor denial that I don’t know how to avoid.

Sia is for shared file storage. When I tried to add a folder with:

sia.client host folder add ~/snap/sia/common/folder 1Gb

I got:

apparmor="DENIED" operation="capable" profile="snap.sia.siad" pid=4095 comm="siad" capability=1 capname="dac_override"

snappy-debug doesn’t tell me how to fix it. Is there a way to keep this snap strict and allow this operation?

Here is the yaml I am using:

https://github.com/elopio/Sia/blob/snapcraft/snap/snapcraft.yaml

2

This is often caused because root is trying to write to a directory or file that it doesn’t have write access to. Eg, root tries to write to a dir that is 0755 and owned by foo:bar. Unconfined root runs with CAP_DAC_OVERRIDE which allows it to write to it. Assuming the problem is what I described, you need to take a look at what the application is doing and either adjust the directory/file permissions or adjust the code in some manner to not trigger this. Also, depending on how the program is written, dac_override may be non-fatal. See man 7 capabilities for details.

1 Like
3

Great info, thanks @jdstrand.

I removed daemon: simple, so now I start the sia daemon manually as the user. This works, with the obvious downside that now I have to start the daemon manually.

This makes a lot of sense, actually. Because running the daemon as root, then all users would have access to all the folders added by other users.

Now we are just missing to be able to autostart the daemon as the user.

4

Note that @mvo is working on a session DBus services PR (slow going due to various emergency, critical and high fixes): https://github.com/snapcore/snapd/pull/2592

That isn’t going to give you what you need (unless your snap is actually a dbus service), but that lays some groundwork for session services in general.

1 Like