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.
Bug 1723265 - recursion fails when broken symlink is present
Summary: recursion fails when broken symlink is present
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: logrotate
Version: 8.1
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: 8.0
Assignee: Kamil Dudka
QA Contact: Frantisek Sumsal
URL:
Whiteboard:
: 2021216 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-06-24 05:34 UTC by Cédric Jeanneret
Modified: 2022-03-16 06:11 UTC (History)
5 users (show)

Fixed In Version: logrotate-3.14.0-4.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-04 01:59:23 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:4538 0 None None None 2020-11-04 01:59:25 UTC

Description Cédric Jeanneret 2019-06-24 05:34:00 UTC
Hello,

Description of problem:
popt as shipped on RHEL-8.1 breaks recursion when we have a broken symlink in the tree.

This is affecting "logrotate" and other application based on popt.

Version-Release number of selected component (if applicable):


How reproducible:
Always (using logrotate as a "popt enabled app")


Steps to Reproduce:
1. create a directory tree with a broken symlink, and put files in that tree
2. configure logrotate to manage this tree
3. run logrotate with "-d" option, using the crafted configuration

Actual results:
popt (hence logrotate) doesn't see anything

Expected results:
popt (hence logrotate) should at least list the files in that tree

Additional info:
An upstream github issue was opened against logrotate first: https://github.com/logrotate/logrotate/issues/251
Apparently popt website doesn't exist anymore, so no way to open a bug on their side.

Thank you!

Cheers,

C.

Comment 1 Panu Matilainen 2019-06-24 07:09:31 UTC
Upstream seems confused, popt does not implement any globbing beyond using glibc's glob() for finding its own config files.
As I pointed out in the upstream ticket, logrotate *could* be affected by this glibc fix to revert a long-standing broken behavior on glob() regarding broken symlinks: https://sourceware.org/bugzilla/show_bug.cgi?id=866.

Reassigning to logrotate, until proven otherwise this is strictly between logrotate and glibc.

Comment 2 Kamil Dudka 2019-06-24 07:49:08 UTC
The upstream bug report you refer to is about a different issue -- whether symlinks should be included in the glob result or not.  However, Cédric is reporting an issue about regular files not being processed when a broken symlink appears in the directory being globbed.  I have not tried to reproduce it myself.  It could be logrotate's issue as you say.

Panu, could you please clarify the situation about popt's upstream?  Does it still exist?

If yes, the URL in popt.spec should be updated.  Do you need a separate bug report for that?

Comment 3 Panu Matilainen 2019-06-24 08:05:56 UTC
We sheltered popt at https://github.com/rpm-software-management/popt just a couple of weeks ago due to upstream vanishing for the second time within a year, but we beyond that I don't know yet what, if anything, is going to happen. So updating URL's is premature at this point.

As for the issue itself, I just pointed out the glibc issue because it seems closely related - I can quite easily imagine code which does not expect to see broken symlinks (due to the longstanding glibc behavior) from glob() doing unexpected things when those broken symlinks are suddenly there again. Unexpected things such as stopping with error code and returning nothing. But that's just a guess, I didn't try reproducing either because I don't see how popt could be involved in this at all.

Comment 4 Kamil Dudka 2019-06-28 16:37:55 UTC
Panu was right.  This is a bug of logrotate.  I have pushed a fix upstream:

https://github.com/logrotate/logrotate/commit/4297f011

Comment 11 errata-xmlrpc 2020-11-04 01:59:23 UTC
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 (logrotate bug fix and enhancement update), 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://access.redhat.com/errata/RHBA-2020:4538

Comment 12 Kamil Dudka 2021-11-08 16:22:33 UTC
*** Bug 2021216 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.