Reading /var/lib/snapd/desktop/(applications,icons}


#1

System: ubuntu 19.04
snap version: 2.42 series 16

On each snap startup it tries to read /var/lib/desktop/icons which is blocked by apparmor:
audit[1901]: AVC apparmor="DENIED" operation="open" profile="snap.firefox.firefox" name="/var/lib/snapd/desktop/icons/" pid=1901 comm="firefox-bin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

Basing on irc discussion /var/lib/snapd/desktop/icons is a new directory introduced in snapd 2.42. The similar path /var/lib/snapd/desktop/applications is allowed to read by multiple interfaces:

according to @jamesh allowing those accesses was unnecessary:

I don’t think it is useful there either, since neither interface provides a way to launch those applications or access e.g. referenced icons

I believe both /var/lib/snapd/desktop/(applications,icons} should be treated the same by either allowing read access or denying it to prevent spam syslogs. I was advised to ask @jdstrand opinion on that matter.


#2

From the discussion on IRC, I suspect we are seeing the audit messages now because they only get generated when access is denied to existing files: not when the process tries to access a path that would be denied if it existed.

Since we add /var/lib/snapd/desktop to $XDG_DATA_DIRS and that setting leaks to the sandbox, it is not surprising that various libraries will try to access paths under that directory. If I created a /var/lib/snapd/desktop/themes directory, I wouldn’t be surprised if I started seeing denial audit messages about that too.

So I propose that we silence denial messages for accesses to /var/lib/snapd/desktop/**, since they are likely to just be noise.

As for the browser-support and desktop-legacy interfaces granting access to /var/lib/snapd/desktop/applications directory, I suspect that this could safely be removed. Neither interface lets sandboxed applications do anything useful with files in that directory (since they don’t allow launching of other snap applications). I kind of wonder if the rule originated in browser-support from seeing the audit messages, without deciding whether the access actually made sense?


#3

@jamesh while waiting for decision about denying whole /var/lib/snapd/desktop/** (which changes existing behavior thus can cause regressions) could you just deny /var/lib/snapd/desktop/icons for now? This is new dir which was never allowed so blocking it should be safe.

Currently it spams we with denials when I run every single snap which is annoying. I would do PR for that myself but I don’t know in which file this rule should go


#4

did you consider just renaming or deleting the dir for the moment to quieten the denials ?


#5

Wouldn’t it come back after delete with snapd update? I think renaming won’t help as it just tries to read all dirs inside /var/lib/snapd/desktop/.


#6

sure, it would come back … i was just referring to the time frame between today and the update of snapd where the fix shows up :wink:
(potentially the next version since it is a tiny “fix” (1 char ?) after all)


#7

My concern is that if I fail to get developers attention this time frame may stretch up to infinity :smile:

I’ll happily deal with this myself while waiting for upstream fix just want be sure there will be something to wait for.