Re: CREDENTIALS_DIRECTORY vs %d

[Gesh <gesh@xxxxxxxxxxx>]

On Thu, Aug 22, 2024 at 03:27:05PM GMT, Lennart Poettering wrote:
> On Do, 22.08.24 15:29, Gesh (gesh@xxxxxxxxxxx) wrote:
> > > > > On Di, 13.08.24 01:28, Gesh (gesh@xxxxxxxxxxx) wrote:
> > > > >
> > > > > > systemd.exec(5) reads:
> > > > > > > In order to reference the path a credential may be read from within a
> > > > > > > ExecStart= command line use "${CREDENTIALS_DIRECTORY}/mycred", e.g.
> > > > > > > "ExecStart=cat ${CREDENTIALS_DIRECTORY}/mycred". In order to reference the
> > > > > > > path a credential may be read from within a Environment= line use "%d/mycred",
> > > > > > > e.g.  "Environment=MYCREDPATH=%d/mycred".
> >
> > I'm not sure how useful the ability to change CREDENTIALS_DIRECTORY
> > via environment variables is in practice, though, on two counts:
> $CREDENTIALS_DIRECTORY is simply *the* *API* from an app
> perspective. it's what we communicate to people as the execution
> context services are invoked in. Hence, even if effectively it should
> always be the same as %d, it's still the thing that consuming apps
> should really use.

Ah, and the Exec* directives are effectively in the overlap between
the service metadata and the actual executable, right? So there's more
room to lean towards writing the invocation with explicit environment
variables rather than specifiers there. That is, everywhere else the
recommendation is to use specifiers, but both of the following make
sense:
> ExecStart=httpd --cert %d/certifcate.pem
> ExecStart=httpd --cert ${CREDENTIALS_DIRECTORY}/certifcate.pem

with the former leaning more towards "metadata semantics" and the
latter more towards "script semantics".

> > - Are there any circumstances where you'd want multiple values for
> >   CREDENTIALS_DIRECTORY within the same service manager?
> > - Even if there are such cases, do they warrant the same amount of
> >   flexibility as general environment variables? Surely this is a bit
> >   of execution context of the same status as the other directives in
> >   `systemd.exec`? (cf the situation around $UID vs User=)
> 
> Note that env vars can be mangled via PAM modules and stuff. And who
> knows what people do there. If they do mangle that env var, i think it
> would be a bad idea, but still, i'd always say: when you consume
> something, make it the env var, nothing else.

Do you mean to say that PAM can mangle the environment that systemd
provides its units? That's unfortunate.

What I had in mind was that either this would be a setting in
systemd/system.conf (and systemd/user.conf) inherited by the units, or
that (under the understanding that directives have better-understood
attribution/configuration than envvars) this should be configured as a
directive in the unit file.

(In other words, this would separate the consumption API from the
configuration API -- while systemd would communicate to the service
executable the location it had chosen for the credentials directory in
CREDENTIALS_DIRECTORY, it would pick that configuration up from .conf
and .service files instead)

Though I'm not sure to what extent this is useful -- the distinction
between systemd-carried variables and envvars, and which we want
where, keeps slipping from me.

Gesh