-
-
Notifications
You must be signed in to change notification settings - Fork 0
Description
With the ongoing work to make Julia applications more distributable, I see a growing chance of a Julia executable used as a systemd service.
Should such a service want to do caching etc. it would be good if BaseDirs
helped it "just do the right thing", by following Table 2 of systemd.exec(5) Sandboxing:
Directory | Below path for system units | Below path for user units | Environment variable set |
---|---|---|---|
RuntimeDirectory= |
/run/ |
$XDG_RUNTIME_DIR |
$RUNTIME_DIRECTORY |
StateDirectory= |
/var/lib/ |
$XDG_STATE_HOME |
$STATE_DIRECTORY |
CacheDirectory= |
/var/cache/ |
$XDG_CACHE_HOME |
$CACHE_DIRECTORY |
LogsDirectory= |
/var/log/ |
$XDG_STATE_HOME /log/ |
$LOGS_DIRECTORY |
ConfigurationDirectory= |
/etc/ |
$XDG_CONFIG_HOME |
$CONFIGURATION_DIRECTORY |
This is particularly important when a service is run under a DynamicUser
and trying to use the "usual" directories is liable to cause permissions errors.
There is currently a little bit of prior art floating around, I've come across https://github.com/asasine/systemd-directories which seems like a useful reference point.
I currently wonder if the presence of these variables should override everything else with BaseDirs.User.{cache,...}(::Project)
and return the relevant sandbox env var? I'm slightly worried about these being set incidentally, since the names are rather generic (as opposed to SANDBOXED_CACHE_DIR
or SYSTEMD_CACHE_DIR
etc.), but we can somewhat mitigate the risk of misinterpreting by checking for INVOCATION_ID
, which systemd sets for all created services as of v232 (the variables in the table are only set after v240). Unfortunately, this is also set for user sessions started by systemd, which makes this a bit less specific than I hoped, but better than nothing.
I'd be keen to hear any thoughts around this.