Distributing systemd user daemon with snap- not possible to define standard unit file?

Hi guys,

I am trying out snapcraft and was really happy with its simplicity to work with. But I have a major issue and I just can’t believe this is the case. Is it really not possible to define a systemd unit file directly? I just can’t believe that my only option is here https://snapcraft.io/docs/services-and-daemons ?? I mean why not just allow us to create a regular , standard systemd unit file, and have snap manage starting that through systemctl? – Is this not possible?

My issue is, I want to create a fairly standard user daemon, which only runs on changes to a file - using the watchPath option of the unit file.

snapd does not let snaps install unit files verbatim because it would make sandbox escape trivial. There are numerous directives that provide commands for systemd to execute. Those commands would be executed by systemd unconfined.

To make it safe, we’d need to validate that the unit file was using a safe subset of directives and that any directives providing commands to execute were rewritten to ensure those commands are run with the correct confinement. It wouldn’t be safe to allow any new directives snapd does not know about, since they may enable command execution.

At that point, having snaps provide unit files would be over-promising on what snapd would deliver. The current yaml based syntax makes it clear what is supported and what isn’t.

Now as for the question of providing units for the user instance of systemd, there is experimental support for that available in snapd right now but gated behind a feature flag. I wrote an outline of this support in this post:

I do hope that this will be turned on by default soon, but can’t give a hard timeline at this point.

2 Likes

This is really helpful - thanks!

I’ll find a workaround for now, and just build the watch functionality into a special executable for the snap distribution until this is more clearly supported.

This is my first time working with snap so I’m getting the hang of it still. I really appreciate the thorough documentation and your quick feedback here.

1 Like

Phew. For a second there I thought you were trying to put systemd into a snap. Then my head exploded :slight_smile:

1 Like

If you have an example of what directives you want to use inside a snap (along with an explanation of the overall feature/what you are trying to accomplish), please feel free to share that, the set of systemd directives we support is ever-evolving and with proper design we would like to support more service use-cases in snaps.

1 Like

@ijohnson Sure - what I’m really trying to create is User Service Unit.

It seems that, because my Snap is a daemon, Snap by default creates it as a System Service Unit - which has root context rather than user context. This is both more privilege level than my service actually needs but also prevents my application from working properly, because I loose all context of the user home drive.

How can I specify directly to snap that this is a User Service Unit? I believe this would also effect how Snap interprets the Plug interfaces.

I don’t see anything here on the docpage for services and daemons - https://snapcraft.io/docs/services-and-daemons.

For that specifically, see @jamesh’s link from comment #2 above, as mentioned it’s not turned on by default yet, but hopefully soon :smile:

Ahh thanks - I see now. This is EXACTLY what I need!

Glad it’s already in the works!

1 Like