Bug 1531125

Summary: Policy files can not be easily recognized in an alternative location on AH
Product: Red Hat Enterprise Linux 7 Reporter: Ruixin Bao <rubao>
Component: polkitAssignee: Polkit Maintainers <polkit-devel>
Status: CLOSED WONTFIX QA Contact: qe-baseos-daemons
Severity: low Docs Contact:
Priority: unspecified    
Version: 7.5CC: fsumsal
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-02-15 07:34:24 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ruixin Bao 2018-01-04 16:01:34 UTC 
Description of problem:

On atomic host (fedora AH 27), we are trying to create a firewalld system container, which involves authentication from policy kit. For visibility of the policy related files from firewalld, we need to copy those from the container onto the host. 

However, the action above can not be done easily as '/usr' directory is a read only fs on Atomic Host. As a result, the policy files will not be recognized, leading to authentication failure when running firewalld container commands. 

The issue has been discussed in the polkit mailing list:
https://lists.freedesktop.org/archives/polkit-devel/2017-December/000566.html

Giuseppe also suggested a work around for the above issue. One way to make policy files recognized would be to allow policy kit to read policy files from an alternative location: '/etc/polkit-1/actions'

Additional info:
The attached link is the patch Giuseppe proposed. https://github.com/giuseppe/polkit/commit/d69e133dcda0d75fae2c00efa2c15a8cb97b4e85

Note: This bugzilla is more like a tracking for the problem/process of work around for the problem mentioned earlier.
Comment 5 RHEL Program Management 2021-02-15 07:34:24 UTC 
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.