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:
Possible regression from BZ # 1533638. The previous BZ notes that the method of implementing this change would be through an environment variable configuration, but then the BZ was closed with an errata release of RHBA-2018:3245 - systemd-219-62 (Original BZ also shows fixed in systemd-219-58.el7)
The github commit appears to have removed that logic from tmpfiles.c altogether, I'm not seeing any record of the environment variable configuration changes mentioned in the original BZ.
https://github.com/lnykryn/systemd-rhel/pull/201/commits/5349b65d33560518d464490aa5a1a63e90295dc6
Customer is running systemd-219-67.el7_7.2 and is encountering "Ignoring: file read-only and owner by root." on files owned by root without the write bit.
This RFE pertains to SFDC # 02524658. Customer noticed certain tmp files were not being cleaned by systemd-tmpfiles:
$ stat old-test-file-owned-by-root
File: ‘old-test-file-owned-by-root’
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: fd00h/64768d Inode: 1192819 Links: 1
Access: (0111/---x--x--x) Uid: ( 0/ root) Gid: ( 0/ root)
Context: unconfined_u:object_r:user_tmp_t:s0
Access: 2019-10-22 18:39:24.676375622 +0100
Modify: 2019-10-22 18:39:24.676375622 +0100
Change: 2019-10-22 18:39:41.020368654 +0100
Birth: -
It was noticed by GSS that this file did not have the write bit set and this logic exists in tmpfiles.c:
/* Do not delete read-only files owned by root */
if (s.st_uid == 0 && !(s.st_mode & S_IWUSR)) {
log_debug("Ignoring \"%s/%s\": read-only and owner by root.", p, dent->d_name);
continue;
}
As such, customer was informed this was intended behavior. Customer requests an RFE to have this logic removed from future releases.
Customer reports this change has already been implemented upstream:
https://github.com/systemd/systemd/commit/a083b4875e8dec5ce5379d8bc437d750cd338c37
Version-Release number of selected component (if applicable):
systemd-219-67.el7_7.2.x86_64
I believe this logic exists in all available versions of tmpfiles.c
How reproducible:
Always
Steps to Reproduce:
1. Remove the write bit from a temporary file owned by root that systemd-tmpfilesd is watching
2. Run systemd-tmpfiles --clean
3. "Ignoring: file read-only and owner by root." message reported
Actual results:
Systemd-tmpfilesd ignores and does not delete the temporary file.
Expected results:
Systemd-tmpfilesd deletes the file regardless of ownership or permissions.
Additional info:
Red Hat Enterprise Linux version 7 entered the Maintenance Support 1 Phase in August 2019. In this phase only qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available.