Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
The UID and GID of any jar files gets reset by brp-java-repack-jars.
I think few people notice this because it's extremely common to manually set those attributes in the %files section.
If however you configure the ownership & perms in the %install section (e.g., with chown, chgrp, chmod) and use "%defattr(-,-,-,-)" in the %files section ... well, then this hurts bad.
Version-Release number of selected component (if applicable):
All. Tried the version of redhat-rpm-config shipped in every RHEL 6 and RHEL 7 release DVD. I didn't try RHEL 5 but I suspect it would be the same.
How reproducible:
100%
Steps to Reproduce:
~~~~~~~~
yum -y install zip rpm-build rpmdevtools
user=mockbuild # or whatever
group=OTHERGRP # or whatever
cat >/tmp/jartest.spec <<EOF
%define __jar_repack %{nil}
Name: jartest
Version: 1.0
Release: 1
Summary: Demonstrate how brp-java-repack-jars messes w/GID
License: GPLv3
Source0: %{name}-%{version}.tar
%description
%{summary}
%prep
%setup -q
%install
rm -vrf %{buildroot}
mkdir -vp %{buildroot}
chgrp -v ${group} number1.jar
mv -v * %{buildroot}
%files
%defattr(-,-,-,-)
/*
EOF
groupadd ${group}
useradd -G ${group} ${user}
su - ${user}
rpmdev-setuptree
cd rpmbuild
mkdir SOURCES/jartest-1.0
zip SOURCES/jartest-1.0/number1.jar /etc/issue
zip SOURCES/jartest-1.0/number2.jar /etc/yum.conf
tar -C SOURCES -cf SOURCES/jartest-1.0.tar jartest-1.0
cp /tmp/jartest.spec SPECS/
rpmbuild -bb SPECS/jartest.spec
rpm -qplv RPMS/x86_64/jartest-1.0-1.x86_64.rpm
# The two jar files are owned by different groups
# Now remove the line disabling java_repack and try again
sed -i.bak 1d SPECS/jartest.spec
rpmbuild -bb SPECS/jartest.spec
rpm -qplv RPMS/x86_64/jartest-1.0-1.x86_64.rpm
# Notice that the jar files are both owned by user's primary group
~~~~~~~~
Additional info:
The latest version of rpm-build added redhat-rpm-config as a dependency which means that some folks are only now running into this.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://rhn.redhat.com/errata/RHBA-2016-0948.html
Description of problem: The UID and GID of any jar files gets reset by brp-java-repack-jars. I think few people notice this because it's extremely common to manually set those attributes in the %files section. If however you configure the ownership & perms in the %install section (e.g., with chown, chgrp, chmod) and use "%defattr(-,-,-,-)" in the %files section ... well, then this hurts bad. Version-Release number of selected component (if applicable): All. Tried the version of redhat-rpm-config shipped in every RHEL 6 and RHEL 7 release DVD. I didn't try RHEL 5 but I suspect it would be the same. How reproducible: 100% Steps to Reproduce: ~~~~~~~~ yum -y install zip rpm-build rpmdevtools user=mockbuild # or whatever group=OTHERGRP # or whatever cat >/tmp/jartest.spec <<EOF %define __jar_repack %{nil} Name: jartest Version: 1.0 Release: 1 Summary: Demonstrate how brp-java-repack-jars messes w/GID License: GPLv3 Source0: %{name}-%{version}.tar %description %{summary} %prep %setup -q %install rm -vrf %{buildroot} mkdir -vp %{buildroot} chgrp -v ${group} number1.jar mv -v * %{buildroot} %files %defattr(-,-,-,-) /* EOF groupadd ${group} useradd -G ${group} ${user} su - ${user} rpmdev-setuptree cd rpmbuild mkdir SOURCES/jartest-1.0 zip SOURCES/jartest-1.0/number1.jar /etc/issue zip SOURCES/jartest-1.0/number2.jar /etc/yum.conf tar -C SOURCES -cf SOURCES/jartest-1.0.tar jartest-1.0 cp /tmp/jartest.spec SPECS/ rpmbuild -bb SPECS/jartest.spec rpm -qplv RPMS/x86_64/jartest-1.0-1.x86_64.rpm # The two jar files are owned by different groups # Now remove the line disabling java_repack and try again sed -i.bak 1d SPECS/jartest.spec rpmbuild -bb SPECS/jartest.spec rpm -qplv RPMS/x86_64/jartest-1.0-1.x86_64.rpm # Notice that the jar files are both owned by user's primary group ~~~~~~~~ Additional info: The latest version of rpm-build added redhat-rpm-config as a dependency which means that some folks are only now running into this.