...
Hi. MongoDB 6.0 running on Rocky Linux 8. We have noticed that the MongoDB server process is denied "write" access to the log file after it is rotated, as per this documentation: https://www.mongodb.com/docs/manual/tutorial/rotate-log-files/#forcing-a-log-rotation-with-sigusr1 Restarting the mongod.service systemd unit does not produce the same denial. It looks like the mongod process is requesting "write" access after the "kill", instead of "append", and being denied access because it has not been granted this permission. MongoDB 5.0 running on Rocky Linux 8 is OK. Additional information: sudo ausearch -m avc time->Tue Sep 20 03:46:01 2022 type=PROCTITLE msg=audit(1663641961.899:759879): proctitle=2F7573722F62696E2F6D6F6E676F64002D66002F6574632F6D6F6E676F642E636F6E66 type=PATH msg=audit(1663641961.899:759879): item=1 name="/var/log/mongodb/mongod.log" inode=8440224 dev=fd:03 mode=0100640 ouid=993 ogid=990 rdev=00:00 obj=system_u:object_r:mongod_log_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PATH msg=audit(1663641961.899:759879): item=0 name="/var/log/mongodb/" inode=8440193 dev=fd:03 mode=040755 ouid=993 ogid=990 rdev=00:00 obj=system_u:object_r:mongod_log_t:s0 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(1663641961.899:759879): cwd="/" type=SYSCALL msg=audit(1663641961.899:759879): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=55d9d0d28a20 a2=241 a3=1b6 items=2 ppid=1 pid=1565 auid=4294967295 uid=993 gid=990 euid=993 suid=993 fsuid=993 egid=990 sgid=990 fsgid=990 tty=(none) ses=4294967295 comm="SignalHandler" exe="/usr/bin/mongod" subj=system_u:system_r:mongod_t:s0 key=(null) type=AVC msg=audit(1663641961.899:759879): avc: denied { write } for pid=1565 comm="SignalHandler" name="mongod.log" dev="dm-3" ino=8440224 scontext=system_u:system_r:mongod_t:s0 tcontext=system_u:object_r:mongod_log_t:s0 tclass=file permissive=0 ps -ef | grep mongo system_u:system_r:mongod_t:s0 mongod 1565 1 2 Sep15 ? 03:17:55 /usr/bin/mongod -f /etc/mongod.conf sudo lsof -p 1565 | grep mongod.log mongod 1565 mongod 6w REG 253,3 32082779 8440194 /var/log/mongodb/mongod.log-20220915 sudo semanage fcontext --list | grep "/var/log/mongodb" /var/log/mongodb(/.*)? all files system_u:object_r:mongod_log_t:s0 sudo sesearch --allow --source mongod_t --target mongod_log_t --class file allow daemon logfile:file { append getattr ioctl lock }; allow domain file_type:file map; [ domain_can_mmap_files ]:True allow mongod_t mongod_log_t:file { append create getattr ioctl lock open rename setattr }; {{}}
JIRAUSER1262924 commented on Thu, 3 Aug 2023 00:38:20 +0000: Hi third.line@invade.net, we assess and prioritize SELinux support improvements on an ongoing basis, along with all other server improvements. Cheers! JIRAUSER1269682 commented on Wed, 2 Aug 2023 08:38:16 +0000: Hi. As this issue has now been open for nearly a year, can I ask how often you assess the iterations of your SELinux support? Thanks. JIRAUSER1262924 commented on Tue, 1 Aug 2023 20:13:43 +0000: Hi third.line@invade.net, thanks again for bringing this to our attention. As there appears to be a workaround, I am moving this to our backlog and we will assess a permanent fix in the next iteration of our SELinux support. JIRAUSER1269682 commented on Tue, 4 Oct 2022 08:52:48 +0000: Hi. I'm not sure that issue is related as it is referring the the file permissions of the log files. We want to keep the default file permissions. This is a SELinux "write" denial. The options as I see it are: Change the code so that the log file is written to using "append" instead of "write". Add "write" access to your policy: https://github.com/mongodb/mongodb-selinux/blob/master/selinux/mongodb.te Based on: https://github.com/SELinuxProject/refpolicy/blob/master/policy/support/file_patterns.spt and: https://github.com/SELinuxProject/refpolicy/blob/master/policy/support/obj_perm_sets.spt I believe this would mean adding either: write_file_perms(mongod_t, mongod_log_t, mongod_log_t) or: rw_file_perms(mongod_t, mongod_log_t, mongod_log_t) JIRAUSER1270794 commented on Mon, 3 Oct 2022 16:36:42 +0000: Hi third.line@invade.net, Thank you for reporting this issue. While I don't have a certain answer for this right now, from the description you provided, it seems similar to SERVER-36251. Can you check and compare the file permissions of the closed log file and the new log file, and see if you agree this issue is the same as SERVER-36251? If so, you can instruct MongoDB log rotation to honor the system umask via the honorSystemUmask server parameter. Otherwise, please let us know. Regards, Yuan JIRAUSER1269682 commented on Mon, 3 Oct 2022 16:08:08 +0000: Just for info. We have temporarily added the following policy to resolve the problem: module mongodb-test 1.0; require { type mongod_t; type mongod_log_t; class file write; } #============= mongod_t ============== allow mongod_t mongod_log_t:file write;
kill -USR1 {PID}