Bug 2058239

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

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

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.

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

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

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

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.

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

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

Moving component to ipa-healthcheck to implement this.

*** Bug 2061532 has been marked as a duplicate of this bug. ***

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

master: 621a32bb892fa36cb2fd78a3f30f6080300b0bef

ipa-healthcheck-0.7-13.el8

Pre-verified using automation in test_replica_promotion.py::TestHiddenReplicaPromotion::test_ipahealthcheck_hidden_replica.
Package version ihealthcheck-0.7-13.module+el8.7.0+15276+08c45309.noarch from the test compose http://artifacts.osci.redhat.com/comp/rhel-8.7.0-mbs/15276-958-idm/


Excerpt of a log:
transport.py               217 DEBUG    Exit code: 0
transport.py               391 INFO     RUN ['ipa-healthcheck', '--output-type', 'json', '--failures-only']
transport.py               513 DEBUG    RUN ['ipa-healthcheck', '--output-type', 'json', '--failures-only']
transport.py               558 DEBUG    []
transport.py               217 DEBUG    Exit code: 0
transport.py               391 INFO     RUN ['ipa-healthcheck', '--output-type', 'json', '--failures-only']
transport.py               513 DEBUG    RUN ['ipa-healthcheck', '--output-type', 'json', '--failures-only']
transport.py               558 DEBUG    []
transport.py               217 DEBUG    Exit code: 0

Full log is available as an attachment of this BZ. Marking as verified: tested.

Verified using the automation from test_replica_promotion.py::TestHiddenReplicaPromotion::test_ipahealthcheck_hidden_replica with the package ipa-healthcheck-0.7-13.module+el8.7.0+15276+08c45309.noarch

Excerpt of the verification log:
transport.py               391 INFO     RUN ['ipa-healthcheck', '--output-type', 'json', '--failures-only']
transport.py               513 DEBUG    RUN ['ipa-healthcheck', '--output-type', 'json', '--failures-only']
transport.py               558 DEBUG    []
transport.py               217 DEBUG    Exit code: 0
transport.py               391 INFO     RUN ['ipa-healthcheck', '--output-type', 'json', '--failures-only']
transport.py               513 DEBUG    RUN ['ipa-healthcheck', '--output-type', 'json', '--failures-only']
transport.py               558 DEBUG    []
transport.py               217 DEBUG    Exit code: 0

Full log is an attachment of this BZ. Marking as verified.

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 (idm:client and idm:DL1 bug fix and enhancement update), 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-2022:7540