Don't expose account names when creating tar files with hard-coded account IDs #1765
Conversation
…count IDs A prerequisite for fixing containers/image#1627 . Signed-off-by: Miloslav Trmač <mitr@redhat.com>
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mtrmac The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
| // Don’t expose the user names from the local system; they probably don’t match the ta.ChownOpts value anyway, | ||
| // and they unnecessarily give recipients of the tar file potentially private data. | ||
| hdr.Uname = "" | ||
| hdr.Gname = "" |
There was a problem hiding this comment.
I wouldn't mind terribly if these two lines weren't conditional on ChownOpts being set.
There was a problem hiding this comment.
Not that that's a blocker, mind.
There was a problem hiding this comment.
@nalind That’s quite attractive, I think it would be a replacement for containers/buildah#4181 (with better performance).
OTOH it would make the archives worse for “ordinary tar” operations — in that case matching by account names better captures the users’ intent than matching by UIDs, in case the tar file is moved to a machine with different ID allocations.
I don’t know what we can automatically tell which one the caller wants… maybe based on ta.ChownOpts != nil || !ta.IDMappings.Empty()?
Or maybe there are no “ordinary tar” callers of this codebase anyway?! There are several callers which use this for non-container-layer purposes, but it seems possible that they are only confined to a single host (where the distinction is moot), to a remote client-server operation (where we don’t want any Chown to happen), or to cross-namespace operations with layer/container data (where the configured ID mappings is what matters).
There was a problem hiding this comment.
Oh, you make a good point about the intent being hard to discern for cases where the names are preferred over IDs. That makes the "filter the output to tailor it" approach more attractive to me in general than trying to add an option field to cover every possible case.
Given the either/or nature of the Uid/Uname and Gid/Gname fields, though, this would be a good exception to such a rule, so LGTM.
There was a problem hiding this comment.
Conceptually, I would prefer for layerStore.Diff and the like to return already-scrubbed tar files (in all situations with all graph drivers); cleaning that only later in Buildah works but feels a bit unclean to me.
The downside is that that ~silently changing the behavior of pkg/{chroot,}archive is a hard-to-manage API transition; at least it would require a detailed analysis of all users (most of which I’m unfamiliar with, notably the Podman checkpoint code).
|
(I have manually tested that this + containers/image#2202 fixes the linked bug.) |
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
|
/lgtm |
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
A prerequisite for fixing containers/image#1627 .