Bug 2072708

+++ This bug was initially created as a clone of Bug #2058239 +++

Description of problem:
ipa-healthcheck --output-type json --failures-only reports

transport.py               558 DEBUG    [
transport.py               558 DEBUG      {
transport.py               558 DEBUG        "source": "ipahealthcheck.ipa.files",
transport.py               558 DEBUG        "check": "IPAFileCheck",
transport.py               558 DEBUG        "result": "WARNING",
transport.py               558 DEBUG        "uuid": "c16f6dc4-d964-4040-b7ba-775ae0b7df54",
transport.py               558 DEBUG        "when": "20220221170749Z",
transport.py               558 DEBUG        "duration": "0.005988",
transport.py               558 DEBUG        "kw": {
transport.py               558 DEBUG          "key": "_var_log_kadmind.log_mode",
transport.py               558 DEBUG          "path": "/var/log/kadmind.log",
transport.py               558 DEBUG          "type": "mode",
transport.py               558 DEBUG          "expected": "0600",
transport.py               558 DEBUG          "got": "0640",
transport.py               558 DEBUG          "msg": "Permissions of /var/log/kadmind.log are too permissive: 0640 and should be 0600"
transport.py               558 DEBUG        }
transport.py               558 DEBUG      }
transport.py               558 DEBUG    ]
transport.py               217 DEBUG    Exit code: 1

This was uncovered after the fix from https://bugzilla.redhat.com/show_bug.cgi?id=2049167

Version-Release number of selected component (if applicable):
krb5-libs-1.18.2-14.el8.x86_64
krb5-pkinit-1.18.2-14.el8.x86_64
krb5-server-1.18.2-14.el8.x86_64
krb5-workstation-1.18.2-14.el8.x86_64

How reproducible:
always

Steps to Reproduce:
Execute the test suite stated in QE whiteboard

Actual results:
"Permissions of /var/log/kadmind.log are too permissive: 0640 and should be 0600"

Expected results:
Permissions should be 0600

Additional info:
Marking as regression, as on RHEL8.5 system, /var/log/kadmind.log has 0600


--- Additional comment from Julien Rische on 2022-03-01 13:59:29 UTC ---

There is an inconsistent behavior between kadmin tools and daemon:

* kadmind creates /var/log/kadmind.log with mode 0640[1]
* kdb5_util creates /var/log/kadmind.log with mode 0600 (still looking for where this is happening in the code)

This inconsistency is still there on RHEL9. I am not sure if this is a regression of krb5 though: it may be due to a change in of kdb5_util's behavior, or to a change in the IPA installation script (in case kdb5_util was executed before kadmind in previous versions).

I still believe it would make more sense to have both kdb5_util and kadmind setting the same mode when creating /var/log/kadmind.log. But should we actually require 0600 mode rather than 0640, since the group is root?

[1] https://github.com/krb5/krb5/commit/9914b93516bbce9b1123ed5f9f796b7028944892#diff-a8cdf56f67ec1a8ee775777d0bed41dc5eae938154b7235e7e220daadf4d3c9fR428

--- Additional comment from Julien Rische on 2022-03-02 11:26:37 UTC ---

The code I mentioned in my previous comment is actually patched[1], but it doesn't change its behavior regarding the mode of /var/log/kadmind.log.

Something I find confusing is the only reference to /var/log/kadmind.log in the strace report of kdb5_util uses the 0640. However, the resulting file has mode 0600.

# strace -e trace=%file -k -o report.strace -- kdb5_util create
...
openat(AT_FDCWD, "/var/log/kadmind.log", O_WRONLY|O_CREAT|O_APPEND, 0640) = 4
 > /usr/lib64/libc.so.6(__open+0x5b) [0x143ddb]
 > /usr/lib64/libkrb5support.so.0.1(krb5int_labeled_open+0x127) [0x6ee7]
 > /usr/lib64/libkadm5srv_mit.so.12.0(krb5_klog_init+0x487) [0xd9d7]
 > /usr/sbin/kdb5_util(kdb5_create+0x3c7) [0x108b7]
 > /usr/sbin/kdb5_util(main+0x4d9) [0x6889]
 > /usr/lib64/libc.so.6(__libc_start_call_main+0x7f) [0x44e4f]
 > /usr/lib64/libc.so.6(__libc_start_main@@GLIBC_2.34+0x7b) [0x44efb]
 > /usr/sbin/kdb5_util(_start+0x24) [0x6f94]
...

[1] https://gitlab.com/redhat/centos-stream/rpms/krb5/-/commit/908aeb56b21e5257cba1fc23c7b1babc7a1c6f3a?page=2#a071e38cf3484f61e8097b4b5e1d588ce19a3688_0_343

--- Additional comment from Julien Rische on 2022-03-02 14:25:38 UTC ---

auditd confirms /var/log/kadmind.log is create with 0600 mode:

type=PATH msg=audit(1646229195.833:303): item=1 name="/var/log/kadmind.log" inode=288175 dev=fd:01 mode=0100600 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:kadmind_log_t:s0 nametype=CREATE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0

Therefore, I don't really understand why the 0640 mode parameter passed to the openat() call detected by strace in my previous comment is not applied.

--- Additional comment from Alexander Bokovoy on 2022-03-03 14:22:14 UTC ---

It may be due to umask difference between systemd service environment and root?

--- Additional comment from Alexander Bokovoy on 2022-03-03 14:22:15 UTC ---

It may be due to umask difference between systemd service environment and root?

--- Additional comment from Julien Rische on 2022-03-03 14:51:51 UTC ---

Good guess! The root user's umask is 0022, but it is overridden to 0077 in the kdb5_util code:

https://github.com/krb5/krb5/blob/krb5-1.19.1-final/src/kadmin/dbutil/kdb5_util.c#L327

--- Additional comment from Julien Rische on 2022-03-04 08:51:54 UTC ---

I think for now we should change the expected permissions in ipa-healtcheck. 0640 shouldn't be considered too permissive, since it is the default mode used by kadmind:

https://github.com/freeipa/freeipa-healthcheck/blob/0.10/src/ipahealthcheck/ipa/files.py#L122

The file mode inconsistency between kadmind and kdb5_util should be fixed upstream.

--- Additional comment from Julien Rische on 2022-03-04 14:20:35 UTC ---

The current situation make it difficult to know what mode to expect on /var/log/kadmind.log:
* The ipa-server-install script will initialize the mode as 0600
* If the admin removed the log file, it will be recreated by kadmind with 0640

ipa-healtcheck is raising a warning is case the file mode is too permissive, and an error in case it is too restrictive[1].

But we don't what to turn the warning we currently have (which may be considered a false negative) into an error.

@rcritten, is there a way to allow multiple file modes in ipa-healtcheck? Or a way to not check group read access?

[1] https://github.com/freeipa/freeipa-healthcheck/blob/0.10/src/ipahealthcheck/core/files.py#L47

--- Additional comment from Rob Crittenden on 2022-03-09 21:01:14 UTC ---

Support for multiple expected modes can be added. We did something similar for owner and group.

Moving component to ipa-healthcheck to implement this.

--- Additional comment from Florence Blanc-Renaud on 2022-03-22 14:08:40 UTC ---



--- Additional comment from Rob Crittenden on 2022-04-05 13:28:09 UTC ---

Upstream PR https://github.com/freeipa/freeipa-healthcheck/pull/255