RFE: user root:root permissions for files in SRPM #2604
Comments
|
Indeed, storing the local user/group into src.rpm makes no sense whatsoever. It's an anachronism from the ancient days before Buildroot was a thing that has somehow survived all the way up to this date. We've made some effort to swipe the symptoms under the carpet (ie avoid pointless warnings when this happens) but might as well address the root cause instead. |
Actually this is not an issue. A user cannot create files they cannot touch or see: if we do the proposed change, if running as root, the file is created owned by root, but anyway, for root the ownership and permission mask are ignored. If running as a user, they cannot create any files not owned by them. So please just store the files as |
|
Yes, the only real change needed here is the stored user/group. I doubt it ever made sense, really |
pmatilai
changed the title
There's no situation where rpmbuild should use uid/gid from either the filesystem or current user. The former made sense in the pre-historic times before Buildroot was a thing, but in the last 20+ years that's always the wrong thing to do. Always. The only user/group info rpm can legitimately use is the one that is explicitly specified in the packaging, and otherwise fallback to root/equivalent. Besides fixing a long-standing annoyance with src.rpm file ownership, this also fixes a regression in 4.19.0 where a non-local or otherwise unresolvable user info could cause a segfault during rpmbuild (RhBug:2248763). Fixes: rpm-software-management#2604
There's no situation where rpmbuild should use uid/gid from either the filesystem or current user. The former made sense in the pre-historic times before Buildroot was a thing, but in the last 20+ years that's always the wrong thing to do. Always. The only user/group info rpm can legitimately use is the one that is explicitly specified in the packaging, and otherwise fallback to root/equivalent. Besides fixing a long-standing annoyance with src.rpm file ownership, this also fixes a regression in 4.19.0 where a non-local or otherwise unresolvable user info could cause a segfault during rpmbuild (RhBug:2248763). Fixes: rpm-software-management#2604
There's no situation where rpmbuild should use uid/gid from either the filesystem or current user. The former made sense in the pre-historic times before Buildroot was a thing, but in the last 20+ years that's always the wrong thing to do. Always. The only user/group info rpm can legitimately use is the one that is explicitly specified in the packaging, and otherwise fallback to root/equivalent. Besides fixing a long-standing annoyance with src.rpm file ownership, this also fixes a regression in 4.19.0 where a non-local or otherwise unresolvable user info could cause a segfault during rpmbuild (RhBug:2248763). Fixes: #2604
There's no situation where rpmbuild should use uid/gid from either the filesystem or current user. The former made sense in the pre-historic times before Buildroot was a thing, but in the last 20+ years that's always the wrong thing to do. Always. The only user/group info rpm can legitimately use is the one that is explicitly specified in the packaging, and otherwise fallback to root/equivalent. Besides fixing a long-standing annoyance with src.rpm file ownership, this also fixes a regression in 4.19.0 where a non-local or otherwise unresolvable user info could cause a segfault during rpmbuild (RhBug:2248763). Fixes: rpm-software-management#2604 (backported from commit a0553eb)
There's no situation where rpmbuild should use uid/gid from either the filesystem or current user. The former made sense in the pre-historic times before Buildroot was a thing, but in the last 20+ years that's always the wrong thing to do. Always. The only user/group info rpm can legitimately use is the one that is explicitly specified in the packaging, and otherwise fallback to root/equivalent. Besides fixing a long-standing annoyance with src.rpm file ownership, this also fixes a regression in 4.19.0 where a non-local or otherwise unresolvable user info could cause a segfault during rpmbuild (RhBug:2248763). Fixes: rpm-software-management#2604 (backported from commit a0553eb)
There's no situation where rpmbuild should use uid/gid from either the filesystem or current user. The former made sense in the pre-historic times before Buildroot was a thing, but in the last 20+ years that's always the wrong thing to do. Always. The only user/group info rpm can legitimately use is the one that is explicitly specified in the packaging, and otherwise fallback to root/equivalent. Besides fixing a long-standing annoyance with src.rpm file ownership, this also fixes a regression in 4.19.0 where a non-local or otherwise unresolvable user info could cause a segfault during rpmbuild (RhBug:2248763). Fixes: #2604 (backported from commit a0553eb)
when building a source RPM, the username and filesystem permissions from the build host are preserved and end up propagating to a machine you extract them onto, e.g.. To be able to reproduce SRPMs, we should have predictable conventions for the permissions and ownership of files.
The idea we have come up with in the reproducibility hackfest was to adopt a git-style model of permission storage, i.e., dropping most information about the unix permissions. This model also just makes more sense, overall, for what source RPMS are.
Additionally, it would be useful to clamp the ownership of the files to root:root--though this will necessitate ensuring that the applications which work with RPM input/output respect this clamping and change the permissions if a user extracts or installs it. (Namely, we don't want a user to install an RPM with files they cannot touch or see)
The text was updated successfully, but these errors were encountered: