Bug 1636765

Summary: ipa-restore set wrong file permissions and ownership for /var/log/dirsrv/slapd-<instance> directory
Product: Red Hat Enterprise Linux 7 Reporter: Luc de Louw <ldelouw>
Component: ipaAssignee: IPA Maintainers <ipa-maint>
Status: CLOSED ERRATA QA Contact: ipa-qe <ipa-qe>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.5CC: frenaud, ldelouw, myusuf, pvoborni, rcritten, ssidhaye, tscherf
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ipa-4.6.6-7.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-31 19:55:19 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 Luc de Louw 2018-10-07 13:50:53 UTC
Description of problem:
When attempting a restore, the permission are set to 755 and ownership root:root for /var/log/dirsrv/slapd-<instance> which causes dirsrv not being able to write to the access log


Version-Release number of selected component (if applicable):


How reproducible:
always

Steps to Reproduce:
1. ipa-restore /tmp/ipa-full-2018-10-02-11-53-58
2. grep log_flush_buffer /var/log/dirsrv/dirsrv/slapd-<instance>/errors [07/Oct/2018:15:12:14.655887136 +0200] - ERR - log_flush_buffer - Unable to open access file:/var/log/dirsrv/slapd-<instance>/access


Actual results:
[root@ipa1 dirsrv]# ll
total 4
drwxr-xr-x. 2 root root 4096 Oct  7 15:11 slapd-<instance>



Expected results:
[root@ipa1 dirsrv]# ll
total 4
drwxrwx---. 2 dirsrv dirsrv 4096 Oct  7 15:20 slapd-<instance>



Additional info:
Can be easily recovered manually by:
chmod 770 slapd-<instance> 
chown dirsrv:dirsrv slapd-<instance>
SELinux context is correct

Comment 2 Rob Crittenden 2018-10-07 15:03:43 UTC
What is the package version of ipa-server?

Comment 3 Luc de Louw 2018-10-08 08:00:52 UTC
(In reply to Rob Crittenden from comment #2)
> What is the package version of ipa-server?

Hi,

It is:
ipa-server-4.5.4-10.el7_5.4.4.x86_64
ipa-server-common-4.5.4-10.el7_5.4.4.noarch

Thanks,

Luc

Comment 4 Alexander Bokovoy 2018-10-08 11:33:01 UTC
Upstream ticket:
https://pagure.io/freeipa/issue/7725

Comment 5 Rob Crittenden 2018-10-08 14:06:35 UTC
Is this a restore on top of an existing IPA installation or an restore on a new system?

Comment 6 Luc de Louw 2018-10-08 14:13:12 UTC
(In reply to Rob Crittenden from comment #5)
> Is this a restore on top of an existing IPA installation or an restore on a
> new system?

It was on a new vanilla RHEL7 latest and greatest system. 

"yum -y install ipa-server ipa-server-dns" followed by the restore attempt.

Comment 7 Rob Crittenden 2018-10-08 14:52:10 UTC
I can duplicate the permission and ownership difference but not the bad behavior. In my test ns-slapd starts and logs fine.

A default install has the log instance as:

drwxrwx---. 2 dirsrv dirsrv 127 Oct  8 10:35 slapd-EXAMPLE-TEST

A restored instance:

drwxr-xr-x. 2 root root 127 Oct  8 10:26 slapd-EXAMPLE-TEST

Comment 8 Luc de Louw 2018-10-08 15:15:18 UTC
(In reply to Rob Crittenden from comment #7)
> I can duplicate the permission and ownership difference but not the bad
> behavior. In my test ns-slapd starts and logs fine.
> 
> A default install has the log instance as:
> 
> drwxrwx---. 2 dirsrv dirsrv 127 Oct  8 10:35 slapd-EXAMPLE-TEST
> 
> A restored instance:
> 
> drwxr-xr-x. 2 root root 127 Oct  8 10:26 slapd-EXAMPLE-TEST

In my case, it was even more strange: the error log has the same permission as the access log and was writable.

When I deleted the access log and ipactl restart, access was created with zero byte size and the same error occurred.

Comment 12 Rob Crittenden 2019-10-01 14:31:31 UTC
CI test.

Fixed upstream
master:
https://pagure.io/freeipa/c/7aec6f10374129d75cd99a4012980516ca535551

Comment 13 Florence Blanc-Renaud 2019-10-02 13:28:15 UTC
CI test

Fixed upstream
ipa-4-8:
https://pagure.io/freeipa/c/940e2ef900d766086a793cfd6b8906e425badac0

Comment 16 Mohammad Rizwan 2019-12-17 08:02:06 UTC
============================= test session starts ==============================
platform linux2 -- Python 2.7.5, pytest-4.6.7, py-1.8.0, pluggy-0.13.1 -- /usr/bin/python2
cachedir: .pytest_cache
metadata: {'Python': '2.7.5', 'Platform': 'Linux-3.10.0-1118.el7.x86_64-x86_64-with-redhat-7.8-Maipo', 'Packages': {'py': '1.8.0', 'pytest': '4.6.7', 'pluggy': '0.13.1'}, 'Plugins': {u'html': u'1.22.1', u'multihost': u'1.1', u'sourceorder': u'0.5', u'metadata': u'1.8.0'}}
rootdir: /usr/lib/python2.7/site-packages/ipatests
plugins: metadata-1.8.0, html-1.22.1, multihost-1.1, sourceorder-0.5
collecting ... collected 3 items

test_integration/test_backup_and_restore.py::TestBackupAndRestore::test_full_backup_and_restore PASSED [ 33%]
test_integration/test_backup_and_restore.py::TestBackupAndRestore::test_full_backup_and_restore_with_removed_users PASSED [ 66%]
test_integration/test_backup_and_restore.py::TestBackupAndRestore::test_full_backup_and_restore_with_selinux_booleans_off PASSED [100%]


Automation ran in LTE mode and passed. Logs provided. Marking the bug as verified.

Comment 18 errata-xmlrpc 2020-03-31 19:55:19 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1083