Red Hat Satellite engineering is moving the tracking of its product development work on Satellite 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 "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. 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 "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-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:
Selinux denial for foreman_rails_t domain to search tftpdir_rw_t
 
Version-Release number of selected component (if applicable):
Satellite 6.8.0 Snap8
foreman-selinux-2.1.0-0.2.rc3.el7sat.noarch

How reproducible:
100%

Steps to Reproduce:
1. Install Sat6.8 with provisioning capsule (tftp+dhcp+dns) enabled

2. Check for SELinux denials

type=AVC msg=audit(1594681116.246:2842): avc:  denied  { search } for  pid=90007 comm="sidekiq" name="tftpboot" dev="dm-0" ino=503328373 scontext=system_u:system_r:foreman_rails_t:s0 tcontext=system_u:object_r:tftpdir_rw_t:s0 

Actual results:
denials

Expected results:
no denials

Additional info:

Can you tell when this happens or how to reproduce? I don't see this denial on my install.

There is a similar BZ:

https://bugzilla.redhat.com/show_bug.cgi?id=1857184

type=AVC msg=audit(1594888202.436:193): avc: denied { search } for pid=10144 comm="ruby" name="tftpboot" dev="vda4" ino=188750462 scontext=system_u:system_r:foreman_rails_t:s0 tcontext=system_u:object_r:tftpdir_rw_t:s0 tclass=dir permissive=0

The difference is that the one is puma/ruby process and yours is sidekiq. So perhaps some background task, but what would touch TFTP?

The other BZ will fix the denial but I would like to know what caused this.

Ok this is dupe, during Rails initialization Bootdisk plugin reads TFTP directory for file existence of grubx64.efi.

*** This bug has been marked as a duplicate of bug 1857184 ***