[pbs-devel] [PATCH backup v3 1/2] http_client: store tickets in the user's config directory

[Maximiliano Sandoval]

Thomas Lamprecht <t.lamprecht at proxmox.com> writes:

> Am 16.04.25 um 14:56 schrieb Maximiliano Sandoval:
>> The environment variable XDG_RUNTIME_DIR is only set if the user is
>> logged into a seat. If, for example, the backup client was run with
>> `sudo` then the ticket would not be a stored.
>> 
>> By storing the ticket in the user's configuration directory, it can be
>> reused later if the user logs out.
>
> Hmm, but XDG_CONFIG_HOME does not have to point to ~/.config, so is
> this really solving the problem?

The xdg crate will error out if XDG_RUNTIME_DIR is not set, however it
will fall back to ~/.config if the XDG_CONFIG_HOME env variable is not
set. That is the key difference.

> Would it maybe be nicer to keep the default in XDG_RUNTIME_DIR and
> fallback to some other mechanism, like kernel keyring or alternatively
> maybe systemd creds?

That could be done. In v1 I proposed simply using `/run/proxmox-backup`
(or /run/user/$uid/proxmox-backup), but a different mechanism could be
used.

Regarding kernel keyring or systemd creds, at least the later requires
root access as of debian 12. An issue common to these three mechanisms
is that they all make assumptions about permissions, the backup client
could be run as an arbitrary user which might not have permissions to
any of /run, the keyring, nor the system credentials.

> The [keyrings manpage] description would make it seem like an ideal
> candidate for such things:
>
> "The Linux key-management facility is primarily a way for various
> kernel components to retain or cache security data, authentication
> keys, encryption keys, and other data in the kernel."
>
> I.e., the ticket _is_ security data and an authentication key that
> needs to be cached. One can even set an expiry time for such keys.
>
>
> [keyrings manpage]: https://manpages.debian.org/bookworm/manpages/keyrings.7.en.html
>
>> Since the tickets are only valid for a limited time, it is not a problem
>> if this file is not automatically cleaned.
>
> But that's also why it certainly isn't a config, so feels IMO also
> wrong besides above point about this being rather a lateral move.

I think this was a massive mental lapsus on my end, this should have
been ~/.cache and definitively not ~/.config.