Re: CREDENTIALS_DIRECTORY vs %d

[Lennart Poettering <mzerqung@xxxxxxxxxxx>]

On Do, 22.08.24 15:29, Gesh (gesh@xxxxxxxxxxx) wrote:

> On Thu, Aug 22, 2024 at 02:01:02PM GMT, Lennart Poettering wrote:
> > On Do, 22.08.24 14:44, Gesh (gesh@xxxxxxxxxxx) wrote:
> >
> > > On Thu, Aug 22, 2024 at 11:57:58AM GMT, Lennart Poettering 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".
> >
> > > At a guess, the `Environment=` directive would either be unaffected or
> > > have unclear semantics (in case of loops) if a user attempted to
> > > override `CREDENTIALS_DIRECTORY`, hence there's no harm in freezing
> > > its resolution; but the `Exec*` directives should be left
> > > influenceable in case the user's configuration requires moving
> > > `CREDENTIALS_DIRECTORY`?
> >
> > i am not sure i follow.
> >
> > Env vars in Exec*= are resolved at the  moment we actually fork off a
> > process, not early. And env vars combine Environment=,
> > EnvironmentFile= and various others sources of env vars in a defined
> > order. It's a complex system of inheritance and overriding.
>
> I was trying to justify the man page in light of our discussion, which
> recommends the environment variable in Exec* and the directive in
> Environment=.
> Given your above preference for directives, I would've expected the
> recommendation to be %d throughout. That this is not the case for
> Exec* directives suggests to me that we want the extra flexibility
> there? I was then left grasping for why one would only want that
> flexibility there, so I guessed it was to avoid the confusing
> situation where (after chasing down environment configurations) we end
> up with:
> ```
> [Service]
> Environment="MYCRED=${CREDENTIALS_DIRECTORY}/mycred"
> Environment="CREDENTIALS_DIRECTORY=/custom/path/to/creds"
> ```
> which would be dependent on the expansion order.
>
> I'm not sure how useful the ability to change CREDENTIALS_DIRECTORY
> via environment variables is in practice, though, on two counts:
> - 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=)

$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.

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.

Lennart

--
Lennart Poettering, Berlin