Hide Forgot
Description of problem: SELinux is preventing /usr/lib/systemd/systemd-journald from read, write access on the file /var/log/journal/f87f5388e20642a8b55dbb44565bcc21/. ***** Plugin restorecon (94.8 confidence) suggests ************************ If необходимо исправить метку. Стандартная метка для /var/log/journal/f87f5388e20642a8b55dbb44565bcc21/: var_log_t. Then можно выполнить restorecon. Do # /sbin/restorecon -v /var/log/journal/f87f5388e20642a8b55dbb44565bcc21/ ***** Plugin catchall_labels (5.21 confidence) suggests ******************* If you want to allow systemd-journald to have read write access on the file Then необходимо изменить метку на /var/log/journal/f87f5388e20642a8b55dbb44565bcc21/ Do # semanage fcontext -a -t FILE_TYPE '/var/log/journal/f87f5388e20642a8b55dbb44565bcc21/' where FILE_TYPE is one of the following: NetworkManager_log_t, abrt_var_log_t, acct_data_t, afs_cache_t, afs_logfile_t, aide_log_t, amanda_log_t, antivirus_log_t, apcupsd_log_t, apmd_log_t, asterisk_log_t, auth_cache_t, bacula_log_t, bitlbee_log_t, boinc_log_t, brltty_log_t, calamaris_log_t, callweaver_log_t, canna_log_t, ccs_var_lib_t, ccs_var_log_t, certmaster_var_log_t, cfengine_log_t, cgred_log_t, checkpc_log_t, chronyd_var_log_t, cinder_log_t, cloud_log_t, cluster_var_log_t, cobbler_var_log_t, condor_log_t, conman_log_t, consolekit_log_t, couchdb_log_t, cron_log_t, ctdbd_log_t, cupsd_log_t, cyphesis_log_t, ddclient_log_t, deltacloudd_log_t, denyhosts_var_log_t, devicekit_var_log_t, dirsrv_snmp_var_log_t, dirsrv_var_log_t, dlm_controld_var_log_t, dnsmasq_var_log_t, dovecot_var_log_t, dspam_log_t, evtchnd_var_log_t, exim_log_t, fail2ban_log_t, faillog_t, fenced_var_log_t, fetchmail_log_t, fingerd_log_t, firewalld_var_log_t, foghorn_var_log_t, fsadm_log_t, gear_log_t, getty_log_t, gfs_controld_var_log_t, glance_log_t, glusterd_log_t, groupd_var_log_t, haproxy_var_log_t, httpd_log_t, icecast_log_t, inetd_log_t, initrc_tmp_t, initrc_var_log_t, innd_log_t, ipa_log_t, ipsec_log_t, iscsi_log_t, iwhd_log_t, jetty_log_t, jockey_var_log_t, kadmind_log_t, keystone_log_t, kismet_log_t, krb5_host_rcache_t, krb5kdc_log_t, ksmtuned_log_t, ktalkd_log_t, lastlog_t, mailman_log_t, mcelog_log_t, mdadm_log_t, minidlna_log_t, mirrormanager_log_t, mongod_log_t, motion_log_t, mpd_log_t, mrtg_log_t, munin_log_t, mysqld_log_t, mythtv_var_log_t, naemon_log_t, nagios_log_t, named_log_t, neutron_log_t, nova_log_t, nscd_log_t, nsd_log_t, ntpd_log_t, numad_var_log_t, openhpid_log_t, openshift_log_t, opensm_log_t, openvpn_status_t, openvpn_var_log_t, openvswitch_log_t, openwsman_log_t, osad_log_t, passenger_log_t, pcp_log_t, piranha_log_t, pkcs_slotd_log_t, pki_ra_log_t, pki_tomcat_log_t, pki_tps_log_t, plymouthd_var_log_t, polipo_log_t, postgresql_log_t, pppd_log_t, pptp_log_t, prelink_log_t, prelude_log_t, privoxy_log_t, procmail_log_t, prosody_log_t, psad_var_log_t, puppet_log_t, puppet_tmp_t, pyicqt_log_t, qdiskd_var_log_t, rabbitmq_var_log_t, radiusd_log_t, redis_log_t, rhev_agentd_log_t, rhsmcertd_log_t, ricci_modcluster_var_log_t, ricci_var_log_t, rpm_log_t, rsync_log_t, rtas_errd_log_t, samba_log_t, sanlock_log_t, sectool_var_log_t, security_t, sendmail_log_t, sensord_log_t, setroubleshoot_var_log_t, shorewall_log_t, slapd_log_t, slpd_log_t, smsd_log_t, snapperd_log_t, snmpd_log_t, snort_log_t, spamd_log_t, speech-dispatcher_log_t, squid_log_t, sssd_var_log_t, stapserver_log_t, stunnel_log_t, syslogd_tmp_t, syslogd_tmpfs_t, syslogd_var_lib_t, syslogd_var_run_t, sysstat_log_t, systemd_coredump_tmpfs_t, thin_aeolus_configserver_log_t, thin_log_t, tomcat_log_t, tor_var_log_t, tuned_log_t, ulogd_var_log_t, user_cron_spool_t, user_tmp_t, uucpd_log_t, var_log_t, varnishlog_log_t, vdagent_log_t, virt_log_t, virt_qemu_ga_log_t, vmware_log_t, watchdog_log_t, winbind_log_t, wtmp_t, xdm_log_t, xend_var_log_t, xenstored_var_log_t, xferlog_t, xserver_log_t, zabbix_log_t, zarafa_deliver_log_t, zarafa_gateway_log_t, zarafa_ical_log_t, zarafa_indexer_log_t, zarafa_monitor_log_t, zarafa_server_log_t, zarafa_spooler_log_t, zebra_log_t, zoneminder_log_t. Then execute: restorecon -v '/var/log/journal/f87f5388e20642a8b55dbb44565bcc21/' ***** Plugin catchall (1.44 confidence) suggests ************************** If вы считаете, что systemd-journald следует разрешить доступ read write к file по умолчанию. Then рекомендуется создать отчет об ошибке. Чтобы разрешить доступ, можно создать локальный модуль политики. Do allow this access for now by executing: # ausearch -c 'systemd-journal' --raw | audit2allow -M my-systemdjournal # semodule -X 300 -i my-systemdjournal.pp Additional Information: Source Context system_u:system_r:syslogd_t:s0 Target Context system_u:object_r:unlabeled_t:s0 Target Objects /var/log/journal/f87f5388e20642a8b55dbb44565bcc21/ [ file ] Source systemd-journal Source Path /usr/lib/systemd/systemd-journald Port <Unknown> Host (removed) Source RPM Packages systemd-231-10.fc25.x86_64 Target RPM Packages Policy RPM selinux-policy-3.13.1-220.fc25.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 4.8.6-300.fc25.x86_64 #1 SMP Tue Nov 1 12:36:38 UTC 2016 x86_64 x86_64 Alert Count 5421 First Seen 2016-11-04 22:31:42 MSK Last Seen 2016-11-06 13:16:15 MSK Local ID 1661a66b-b325-4424-8a54-7507b4ed3bf2 Raw Audit Messages type=AVC msg=audit(1478427375.204:2844): avc: denied { read write } for pid=648 comm="systemd-journal" name="user-1000.journal" dev="sda3" ino=151725 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0 type=SYSCALL msg=audit(1478427375.204:2844): arch=x86_64 syscall=open success=no exit=EACCES a0=5590f8b731e0 a1=80042 a2=1a0 a3=5590f8b731e0 items=2 ppid=1 pid=648 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=systemd-journal exe=/usr/lib/systemd/systemd-journald subj=system_u:system_r:syslogd_t:s0 key=(null) type=CWD msg=audit(1478427375.204:2844): cwd=/ type=PATH msg=audit(1478427375.204:2844): item=0 name=/var/log/journal/f87f5388e20642a8b55dbb44565bcc21/ inode=151629 dev=00:26 mode=042755 ouid=0 ogid=190 rdev=00:00 obj=system_u:object_r:var_log_t:s0 nametype=PARENT type=PATH msg=audit(1478427375.204:2844): item=1 name=/var/log/journal/f87f5388e20642a8b55dbb44565bcc21/user-1000.journal inode=151725 dev=00:26 mode=0100640 ouid=0 ogid=190 rdev=00:00 obj=system_u:object_r:unlabeled_t:s0 nametype=NORMAL Hash: systemd-journal,syslogd_t,unlabeled_t,file,read,write Version-Release number of selected component: selinux-policy-3.13.1-220.fc25.noarch Additional info: reporter: libreport-2.8.0 hashmarkername: setroubleshoot kernel: 4.8.6-300.fc25.x86_64 type: libreport Potential duplicate: bug 1295046
I ran into this same problem on my Fedora 25 Workstation today. Which is weird because I have not needed to even look at the systemd journal in weeks. Either the SELinux policy changed what it expects for the journal files, or the journal somehow changed its own file contexts. Right?
Or this file object got created before SELinux policy was loaded into the kernel. unlabeled_t means a file exists on the OS without a label. If one of these shows up on a system after the machine was correctly labeled, I can only think of 3 ways this could happen. A file system is newly created and mounted, which would have the root "/" of the file system without a label. A file was mv'd off of a file system without a label, for example sticking a usb stick with ext4 file system without labels into a system and then mv USBSTICKPATH/foobar /etc. Lastly would be if the initramfs/systemd created a file object before loading SELinux policy into the kernel.
Description of problem: Happened just after booting the system. Normal operation otherwise. It was also a pretty fresh install: one week old, and I didn't mess with any SELinux labels. Version-Release number of selected component: selinux-policy-3.13.1-225.6.fc25.noarch Additional info: reporter: libreport-2.8.0 hashmarkername: setroubleshoot kernel: 4.9.7-201.fc25.x86_64 type: libreport
I also found this snippet in dmesg, which shows some journald activity before loading the SELinux policy: [ 3.677878] systemd-journald[190]: Received SIGTERM from PID 1 (systemd). [ 3.691652] systemd: 17 output lines suppressed due to ratelimiting [ 3.760024] SELinux: 32768 avtab hash slots, 106816 rules. [ 3.769529] SELinux: 32768 avtab hash slots, 106816 rules. [ 3.793364] SELinux: 8 users, 14 roles, 5070 types, 305 bools, 1 sens, 1024 cats [ 3.793366] SELinux: 94 classes, 106816 rules [ 3.796190] SELinux: Permission validate_trans in class security not defined in policy. [ 3.796199] SELinux: Permission module_load in class system not defined in policy. [ 3.796284] SELinux: the above unknown classes and permissions will be allowed [ 3.796288] SELinux: Completing initialization. [ 3.796289] SELinux: Setting up existing superblocks. [ 3.807786] systemd[1]: Successfully loaded SELinux policy in 74.502ms. [ 3.833084] systemd[1]: Relabelled /dev and /run in 14.946ms. [ 3.973756] BTRFS info (device sda4): disk space caching is enabled [ 4.003693] systemd-journald[511]: Received request to flush runtime journal from PID 1
Could systemd be creating this directory before policy is loaded?
Created attachment 1249789 [details] Log section showing journald is started twice It is possible, but I don't know how to check this. However, searching through the log I found that systemd-journald is activated twice: -once early in the boot process, before the rootfs disk is even mounted -and once after the SELinux policy is loaded It is possible the folder and enclosing files are created by the first activation dumping the log, when it's stopped just before loading the SELinux policy. A attached a section of the log showing this behavior.
We might need a patch into systemd to fix the labels of objects created before SELinux is loaded into the kernel.
I am not that familiar with the boot process. Is this a Fedora problem? Or a standard systemd thing?
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.