Named sockets naming

snapd
1

I could not find a better documentation than https://snapcraft.io/docs/snapcraft-yaml-schema’s listen-stream that mentions:

UNIX socket syntax: $SNAP_DATA/<path>, $SNAP_COMMON/<path> and @snap.<snap name>.<suffix>

New crash reporter code for Firefox uses unix named sockets with the name being formatted from "gecko-crash-helper-pipe.{pid:}".

It looks like this makes snap unhappy:

Log: apparmor=“DENIED” operation=“bind” class=“net” profile=“snap.firefox_devlocal.firefox” pid=3038100 comm=“firefox” family=“unix” sock_type=“seqpacket” protocol=0 requested=“bind” denied=“bind” addr=“@gecko-crash-helper-pipe.3038100”

But I could not find any relevant documentation on those requirements. Is there a way to allow the existing name of the socket or we absolutely have to rename it? Where is the bind deny definition living? Searching in apparmor files i could not find.

2

Has this already landed in Firefox? Do you have a LP bug already maybe?

3

Yes, it has already landed. No, I dont have a launchpad issue for that, why would I need one?

4

We could ship a workaround by renaming the crash reporter socket, however I’m concerned about potential third parties that may trip that.

5

There is no listen-stream in Firefox’ snapcraft.yaml. The documentation does not state for what listen-stream is intended, but maybe that is it.

6

You also did not state in which channel of Firefox this is to be expected.

7

that’s my point: i have no idea what precisely is this listen-stream, a few hints suggests this may be related to sockets of daemon services, but it’s not clear.

8

Fix landed in https://bugzilla.mozilla.org/show_bug.cgi?id=1961507 so technically it should be fine, it would still be nice to know if this can impact third parties that may run (drivers, etc.)

9

It only makes sense in context of daemons & socket activation. Perhaps the docs need an update to make it more clear.

10

It would also be nice to get proper documentation that any named socket needs to follow that, or if there’s a way to grant access from the yaml ?

11

it’s going to ride the train, so on beta in a few days

12

@mborzecki1 any news on that matter?

13

Sorry, I don’t follow. You mean a way to override the abstract socket name allowed by the sandbox? No, there is none.

14

Well, the question was not just about that but also seeking confirmation that this was the intended behavior, since it looks rather intrusive. Maybe this is something that could be fixed in the future?

15

There’s patterns elsewhere in snapd that follow this, for example, you can’t place arbitrary files in /dev/shm/, they have to follow a prefix of snap.$SNAP_NAME, because otherwise your app can just poke around at /dev/shm/ being used by any process.

Snap tends heavily towards defaulting to denying operations and using interfaces to relax the restrictions rather than allowing by default; abstract sockets are included in this when you consider e.g., what e.g., leaving the abstract X11 socket open would mean, should the default policy not prevent e.g., a command line application from being able to read the keyboard even if it doesn’t need that scope.

For Firefox, you might have an exception in that you’d likely be able to modify the browser-support interface in snapd itself in order to get access to that abstract socket without renaming it. Whether this is preferable would come down really to how likely it is for this to be upstreamed (possibly so, given half the browser-support interface is built for Firefox and Chromium themselves) and then how long it would take for people to download a newer snapd version with the changes in so they begin to apply it.

Renaming it avoids having to worry about that entirely.

1 Like
16

It’s okay if we need to change on our side, the fix was quick and is riding the train that’s not really a problem, the bigger issue here I see is more the doc was hard to find if existing at all, and I’m always worried a bit about third parties we may have to interact to, if they dont have proper support of Snap (but I dont know any, so maybe that’s not a real problem).