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.
DescriptionVladimir Dulava
2016-11-14 08:10:02 UTC
Description of problem:
RPMs for sudo in RHEL 6.8 and 7.2 are inconsistent
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
The src rpms
sudo-1.8.6p3-24.el6.src.rpm
sudo-1.8.6p7-17.el7.src.rpm
(and probably many other sudo RPMs in various Redhat Linux releases) apply a large number of patches to the original sudo source tree before compiling the code. However, these patches leave the source tree in an inconsistent state, so that some subsequent patches can no longer be applied.
The files def_data.h and def_data.c in the subdirectory plugins/sudoers of the source tree are generated from def_data.in in the same directory via the perl script mkdefaults. The patches, however, only apply changes to def_data.h and def_data.c. In particular, def_data.h and def_data.c can no longer be generated from def_data.in. Patches that correctly apply changes to def_data.in and use mkdefaults to create def_data.h and def_data.c overwrite the changes added by the previous patches to def_data.c and def_data.h. This usually means that the code no longer compiles, as the new definitions in def_data.h are missing.
Expected results:
HOW TO DO IT CORRECTLY
A correct patch to def_data.h and def_data.c should always include the changes to def_data.in. It is OK to include the changes to def_data.h and def_data.c, because by default, the sudo source code does not automatically recreate def_data.h and def_data.c. Only when using the --enable-devel configure option will mkdefaults be run (I consider this a weakness of the sudo build system, although an understandable one).
Using the --enable-devel option is discouraged though because it also leads to the building of the testsudoers.c program, which has additional build requirements not specified in the spec file, leading to build failure.
To fix this problem, a patch that changes def_data.h and def_data.c should always be created by first changing def_data.in, and then running
perl mkdefaults -o def_data def_data.in
manually in plugins/sudoers. This will recreate def_data.h and def_data.c consistent with def_data.in. From this a patch file for all three files def_data.in, def_data.h and def_data.c can then be generated. A patch file generated in this way will always leave the source tree in a consistent state.
Additional info:
This was fixed with rebase in RHEL7.4. We cannot use --enable-devel in our build system because of few more dependencies and stability. But patches are modifying *.in *.c *.h so we are able to compile sudo with or without DEVEL macro correctly and patched.