From: Gabriel Goller <g.goller@proxmox.com>
To: Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [RFC proxmox-backup 2/2] pxar: extract: make invalid ACLs non-fatal
Date: Thu, 10 Oct 2024 16:53:22 +0200 [thread overview]
Message-ID: <20241010145322.mqevcw62uh7cze3f@luna.proxmox.com> (raw)
In-Reply-To: <20241008083355.181031-2-f.gruenbichler@proxmox.com>
On 08.10.2024 10:33, Fabian Grünbichler wrote:
>these can occur in practice, and neither setting nor getting them throws an
>error. if "invalid" ACLs are non-restorable, this means that creating a pxar
>archive with such an ACL is possible, but restoring it isn't.
>
>reported in our community forum:
>https://forum.proxmox.com/threads/155477
>
>Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
>---
>
>Notes:
> we could also forbid creation of course, but since other tools might create
> such ACLs, this would just reduce what we can backup in practice.. and
> doesn't solve the issue for users that have such backups..
If we go this way, then we could implement something like the
`--skip-e2big-xattr` option.
> another alternative approach would be to detect and handle certain kinds of
> invalidity, e.g., with multiple entries for a single uid/gid, we could drop all
> but the most restrictive one, and require the resulting ACL to still pass `acl_valid`.
We could make it quite 'correct' by also merging entries (when duplicate
user/groups appear) and add empty user/group/other entries if none are
existing [0].
But I don't think it's quite worth it tbh. This approach looks fine to
me.
> pbs-client/src/pxar/metadata.rs | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Patch is trivial, but nonetheless consider:
Tested-by: Gabriel Goller <g.goller@proxmox.com>
[0]: https://man7.org/linux/man-pages/man3/acl_valid.3.html
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
next prev parent reply other threads:[~2024-10-10 14:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-08 8:33 [pbs-devel] [PATCH proxmox-backup 1/2] pxar: add file name to path_info when applying metadata Fabian Grünbichler
2024-10-08 8:33 ` [pbs-devel] [RFC proxmox-backup 2/2] pxar: extract: make invalid ACLs non-fatal Fabian Grünbichler
2024-10-10 14:53 ` Gabriel Goller [this message]
2024-11-22 9:26 ` [pbs-devel] [PATCH proxmox-backup 1/2] pxar: add file name to path_info when applying metadata Thomas Lamprecht
2024-11-22 9:42 ` [pbs-devel] applied-series: " Fabian Grünbichler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241010145322.mqevcw62uh7cze3f@luna.proxmox.com \
--to=g.goller@proxmox.com \
--cc=pbs-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.