Description of problem: When trying to upload new images for the undercloud infrastructure as part of the 16.1.5 overcloud upgrade with: OS_CLOUD=undercloud openstack overcloud image upload --image-path $(pwd)/images/ --update-existing the upload fails with: Apr 13 17:14:14 director1 account-server[6574]: ERROR __call__ error with PUT /d1/123/AUTH_970f54f789eb45e29ae432d1e7342221 : #012Traceback (most recent call last):#012 File "/usr/lib/python3.6/site-packages/swift/account/server.py", line 291, in __call__#012 res = getattr(self, req.method)(req)#012 File "/usr /lib/python3.6/site-packages/swift/common/utils.py", line 1982, in _timing_stats#012 resp = func(ctrl, *args, **kwargs)#012 File "/usr/lib/python3.6/site- packages/swift/account/server.py", line 166, in PUT#012 broker.initialize(timestamp.internal)#012 File "/usr/lib/python3.6/site-packages/swift/common/db.p y", line 281, in initialize#012 fd, tmp_db_file = mkstemp(suffix='.tmp', dir=self.db_dir)#012 File "/usr/lib64/python3.6/tempfile.py", line 344, in mkstem p#012 return _mkstemp_inner(dir, prefix, suffix, flags, output_type)#012 File "/usr/lib64/python3.6/tempfile.py", line 262, in _mkstemp_inner#012 fd = _os.open(file, flags, 0o600)#012PermissionError: [Errno 13] Permission denied: '/srv/node/d1/accounts/123/870/1ed2a87e7530a3e6b2e985422952c870/tmpioohxns8.tmp ' (txn: txa9a00d996b184158a13ee-006075d166) Version-Release number of selected component (if applicable): 16.1.5 How reproducible: 100% of the times Steps to Reproduce: 1. Upgrade director to OSP release 16.1.5 2. Run OS_CLOUD=undercloud openstack overcloud image upload --image-path $(pwd)/images/ --update-existing 3. See it fail with an error 500 which corresponds to the above PermissionDenied on the target swift server container Actual results: The upload fails with an error 500 which corresponds to the above PermissionDenied on the target swift server container Expected results: The upload succeeds Additional info: The following custom policies fixes the problem: [stack@director1 ~]$ cat openstack-selinux-custom.te module openstack-selinux-custom 1.0; require { type container_t; type swift_data_t; class file { append ioctl link unlink create lock open read setattr write getattr rename }; class dir { create remove_name read write add_name }; } #============= container_t ============== allow container_t swift_data_t:dir { add_name create read remove_name write }; allow container_t swift_data_t:file { append create ioctl link lock open read setattr unlink write getattr rename };
Hi, thank you for the report. Most of these rules should be covered by https://github.com/redhat-openstack/openstack-selinux/commit/d1e3cb9409f8579a53bee6004e83d0be7ec9780a, though that would not be out yet for 16.1. Looking closer, this looks eerily similar to bug 1941412, where the SELinux issue was only a symptom and not the root cause. It was due to the new containers not being restarted because the image tag hadn't changed, so I think it would be worthwhile to try one of the workarounds described in https://access.redhat.com/solutions/5896881 first and see if that helps. If that doesn't work, could you please reproduce the problem in permissive mode and attach the permissive audit logs, as well as confirm the openstack-selinux version on the system? If I provided you with a test package that includes the commit above, would you be able to test it on the system? Thank you.
Julie, I can confirm https://access.redhat.com/solutions/5896881 was the actual problem we were experiencing, thanks, I believe this can be closed or be made a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1941412, thanks!
Glad the workaround worked, thank you for following up! *** This bug has been marked as a duplicate of bug 1941412 ***