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.
Well, it looks like this relates with
os.system("createrepo /tmp/path")
which I believe could be dontaudited.
Also I would start to think about a new domain for your script.
Miroslav and Karel,
I think this bz should be moved back to the createrepo component
I was under the impression that this bug was an issue with createrepo and not the SELinux policy.
My understanding is:
createrepo runs some initialization code accessing /var/lib/rpm/Packages
for the use case described here this initialization code is probably not needed, the SELinux policy does the right thing and stops createrepo running under httpd_t from accessing /var/lib/rpm/Packages.
I think the fix is to modify createrepo so it does not try to access /var/lib/rpm/Packages, maybe provide a CLI option to skip this or some other means.
Intent is to avoid needing the dontaudit.
For short term, we are including a dontaudit in our SELinux Policy. This bugzilla is to address the long term work on createrepo.
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.
I'm not sure what you expect createrepo to do here. The access is probably from:
ts = rpmUtils.transaction.initReadOnlyTransaction()
...which uses /var/lib/rpm by default, in theory we could create a tmp. dir. and do:
ts = rpmUtils.transaction.initReadOnlyTransaction(root=myemptyrpmroot)
...but it feels like working around the problem, in that what you really need to say is some policy like "when running createrepo from httpd_t we need to change to createrepo_t" or something.
Well did the repo actually get created? IE If we can dontaudit access to rpm from apache, and the tool works we are ok. Although not sure sure what leak happens allowing httpd to read rpm data.
Description of problem: When createrepo is run from within Apache, os.system("createrepo /tmp/path"), genpkgmetada logs several AVC denials. Functionality of createrepo appears to be fine. Below BZ from Katello is related: https://bugzilla.redhat.com/show_bug.cgi?id=784280 Version-Release number of selected component (if applicable): createrepo-0.9.8-4.el6.noarch How reproducible: Always Steps to Reproduce: 1. setenforce 1 2. Restart Apache 3. Create a test script to run from Apache 4. Have script run "createrepo /tmp/path" 5. Look at /var/log/audit/audit.log Actual results: From /var/log/audit/audit.log type=AVC msg=audit(1327660258.845:157981): avc: denied { search } for pid=13209 comm="genpkgmetadata." name="rpm" dev=dm-0 ino=22151171 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:rpm_var_lib_t:s0 tclass=dir type=AVC msg=audit(1327660258.852:157982): avc: denied { getattr } for pid=13209 comm="genpkgmetadata." path="/var/lib/rpm" dev=dm-0 ino=22151171 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:rpm_var_lib_t:s0 tclass=dir type=AVC msg=audit(1327660258.853:157983): avc: denied { open } for pid=13209 comm="genpkgmetadata." name="Packages" dev=dm-0 ino=22413353 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:rpm_var_lib_t:s0 tclass=file type=AVC msg=audit(1327660401.732:158334): avc: denied { open } for pid=16251 comm="genpkgmetadata." name="Packages" dev=dm-0 ino=22413353 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:rpm_var_lib_t:s0 tclass=file type=AVC msg=audit(1327660454.748:158447): avc: denied { search } for pid=17593 comm="genpkgmetadata." name="rpm" dev=dm-0 ino=22151171 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:rpm_var_lib_t:s0 tclass=dir type=AVC msg=audit(1327660454.749:158448): avc: denied { getattr } for pid=17593 comm="genpkgmetadata." path="/var/lib/rpm" dev=dm-0 ino=22151171 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:rpm_var_lib_t:s0 tclass=dir Expected results: No AVCs Additional info: