Feature Request: Conditional Application of systemd Drop-In Files

[adrelanos]

Component

systemd

Is your feature request related to a problem? Please describe

Currently, systemd supports the use of drop-in files to extend or override configuration settings for unit files. While systemd provides the ConditionPathExists directive to conditionally start a service based on the existence of a file or directory, there is no built-in mechanism to conditionally apply drop-in files based on custom conditions within those files.

It would be highly beneficial to have a feature in systemd that allows for the conditional application of drop-in files based on custom conditions. This would provide users with greater flexibility and control over the configuration of systemd units.

A specific example would be the following one:

• Harden all system services by default Kicksecure/security-misc#213

Complex hardening would be enabled by default. But to easily opt-in/out the additional hardening, to simplify testing, a status file would be helpful.

Describe the solution you'd like

Introduce a new directive, such as ConditionDropIn, that allows users to specify custom conditions within drop-in files themselves. This directive could accept a condition expression similar to other systemd directives, enabling users to define conditions based on various factors such as the existence of specific files, system properties, environment variables, or other runtime conditions.

Example:

/lib/systemd/system/myservice.service.d/50_drop-in.conf

[Service]
ConditionDropIn=Exists:/path/to/status/file

# Additional configuration specific to the condition, which is disregarded if the status file does not exist.

In this example, the drop-in file 50_user.conf would only be applied if the file /path/to/status/file exists.

Describe alternatives you've considered

Packaging, scripting.

The systemd version you checked that didn't have the feature you are asking for

No response

[bluca]

This can't really be implemented, it would be a by-the-book TOCTOU as the files are read on reload only, not when a service is started, so the condition would be evaluated at the wrong time

[adrelanos]

Can't it be evaluated by the same time ConditionPathExists is evaluated? A status file in /etc/opt-in-or-out-this-feature would be available already.

[bluca]

No, because again that would make the configuration change randomly outside of reload time, and we do not want that to happen

[adrelanos]

Make it same as ConditionPathExists, only update ConditionDropIn at reload time?

[bluca]

That would mean having some 'special' directive that doesn't mean anything in a file but means something in a different file, and also it means that the provenance of an option becomes important, and also make the actual configuration dependent on random other factors. I don't think that makes much sense. If you want complex configuration management, either use one of the existing config management tools or build a new one.

[septatrix]

I too would really like this feature and would have no problem with the directive being applied at reload time instead of unit startup time. One advantage would be that unit files provided upstream could be even more precise/better. E.g. different properties based on distribution or filesystem layout. Another area where this would make sense even for unit files provided by the distro would be scenarios where different properties should be selected based on the presence of security mechanism like selinux or based on Kernel versions.

Sure, some of this would be possible by changes in the application itself but not everything (anything apart from changes to the execstart cmdline or maybe environment would be considerably harder if not impossible).