From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <pbs-devel-bounces@lists.proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 180461FF15C for <inbox@lore.proxmox.com>; Fri, 18 Apr 2025 14:58:03 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E976F3BD52; Fri, 18 Apr 2025 14:57:58 +0200 (CEST) References: <20250416125651.334868-1-m.sandoval@proxmox.com> <af6e3b28-768d-424e-ada7-ce9d7977362e@proxmox.com> User-agent: mu4e 1.10.8; emacs 30.1 From: Maximiliano Sandoval <m.sandoval@proxmox.com> To: Thomas Lamprecht <t.lamprecht@proxmox.com> Date: Fri, 18 Apr 2025 14:47:21 +0200 In-reply-to: <af6e3b28-768d-424e-ada7-ce9d7977362e@proxmox.com> Message-ID: <s8ott6liq4q.fsf@proxmox.com> MIME-Version: 1.0 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.096 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] [PATCH backup v3 1/2] http_client: store tickets in the user's config directory X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion <pbs-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pbs-devel>, <mailto:pbs-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pbs-devel/> List-Post: <mailto:pbs-devel@lists.proxmox.com> List-Help: <mailto:pbs-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel>, <mailto:pbs-devel-request@lists.proxmox.com?subject=subscribe> Reply-To: Proxmox Backup Server development discussion <pbs-devel@lists.proxmox.com> Cc: Proxmox Backup Server development discussion <pbs-devel@lists.proxmox.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pbs-devel-bounces@lists.proxmox.com Sender: "pbs-devel" <pbs-devel-bounces@lists.proxmox.com> Thomas Lamprecht <t.lamprecht@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. _______________________________________________ pbs-devel mailing list pbs-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel