Bug 1434924

Summary: ipa-restore fails when umask is set to 0027
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: medium Docs Contact:
Priority: unspecified    
Version: 7.3CC: frenaud, myusuf, ndehadra, pasik, pvoborni, rcritten, tscherf
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ipa-4.6.4-1.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-10-30 10:55:57 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 2017-03-22 15:29:56 UTC
Description of problem:

Some organizations are setting the umask to 0027 due to security baselines according to regulations or company internal rules


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


How reproducible:
Always


Steps to Reproduce:
1. ipa-backup --online --data
2. ipa-restore --online --data /back/up/dir
3. IPA server crippled

Actual results:
/var/lib/dirsrv/slapd-EXAMPLE-COM/ldif/EXAMPLE-COM-ipaca.ldif
/var/lib/dirsrv/slapd-EXAMPLE-COM/ldif/EXAMPLE-COM-userRoot.ldif

and probably others do not provide access rights for the dirsrv user, in this case 0600


Expected results:
ipa-restore should manually set 0644 for those files to avoid the directory server not starting anymore


Additional info:

Mitigation:

Set the umask to 0022 (at least temporary)
systemctl start dirsrv@EXAMPLE-COM (if nor running anymore)
re-run ipa-restore --online --data /back/up/dir

Comment 2 Petr Vobornik 2017-03-31 13:44:46 UTC
Upstream ticket:
https://pagure.io/freeipa/issue/6844

Comment 3 Petr Vobornik 2017-03-31 13:50:21 UTC
It's a bug, will be probably fixed in next major upstream version.

Comment 4 Petr Vobornik 2017-12-12 17:21:40 UTC
master:

    28f7eda ipa-restore: Set umask to 0022 while restoring

ipa-4-6:

    74fcdef ipa-restore: Set umask to 0022 while restoring

Comment 7 Mohammad Rizwan 2018-08-13 09:12:43 UTC
version:
ipa-server-4.6.4-3.el7.x86_64

Steps:
1. install ipa server
2. ipa-backup --online --data
3. set umask to 0077 to ensure successful restore
4. ipa-restore --online --data /back/up/dir
5. check umask set to 002 while restore (confirm from console output)
6. check file permissions set to 644 and user and group are dirsrv

   $ stat -c "%U:%G:%a" /var/lib/dirsrv/slapd-TESTRELM-TEST/ldif/TESTRELM-TEST-ipaca.ldif
  
   $ stat -c "%U:%G:%a" /var/lib/dirsrv/slapd-TESTRELM-TEST/ldif/TESTRELM-TEST-userRoot.ldif

Actual result:

[root@master ~]# umask 0077
[root@master ~]# umask
0077

[root@master ~]# ipa-restore --online --data /var/lib/ipa/backup/ipa-data-2018-08-13-04-50-37
Directory Manager (existing master) password: 

Preparing restore from /var/lib/ipa/backup/ipa-data-2018-08-13-04-50-37 on master.testrelm.test
Performing DATA restore from DATA backup
Temporary setting umask to 022                    <<<<<<<<<<<<<<<<<<<
Restoring data will overwrite existing live data. Continue to restore? [no]: yes
Each master will individually need to be re-initialized or
re-created from this one. The replication agreements on
masters running IPA 3.1 or earlier will need to be manually
re-enabled. See the man page for details.
Disabling all replication.
Starting Directory Server
Restoring from userRoot in TESTRELM-TEST
Waiting for LDIF to finish
Restoring from ipaca in TESTRELM-TEST
Waiting for LDIF to finish
Restoring umask to 63
The ipa-restore command was successful

[root@master ~]# umask
0077

[root@master ~]# stat -c "%U:%G:%a" /var/lib/dirsrv/slapd-TESTRELM-TEST/ldif/TESTRELM-TEST-ipaca.ldif 
dirsrv:dirsrv:644

[root@master ~]# stat -c "%U:%G:%a" /var/lib/dirsrv/slapd-TESTRELM-TEST/ldif/TESTRELM-TEST-userRoot.ldif 
dirsrv:dirsrv:644


Expected result:

ipa-restore success. Files permission set to 644 and ownership to dirsrv.
umask temporarily set to 002 while restore.

Based on above observations making the bug as verified.

Comment 11 errata-xmlrpc 2018-10-30 10:55:57 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-2018:3187