There may have been updates to Selinux installed via "dnf upgrade", which I have down quite a few times.Tim:You could use the file, less, cat, or hexdump commands. "file" would try to identify it, the others will just show you the contents for you to try and identify it. If it's zero bytes in size, the system is probably just using the name of the file, itself, to do a job.Stephen Morris:What I'm trying to determine is why journal-offline get a security failure on that file and not the equivalent file that has system before the @, especially when all 4 files in /var/log/journal are owned by root. If the ".#" is removed and the suffix after journal is removed then that file seems to be being persisted across boots, or is being deleted and recreated across boots, so why should there be an selinux issue and is it a bug?Well, I was just answering the identifying what the file was question. But, SELinux applies its rules to new files based on filepaths/names. When files are written, SELinux labels it according to its rules. If I create any old file in my homespace, it's likely to get the context of "unconfined_u:object_r:user_home_t:s0" [tim@fluffy ~]$ touch nothing [tim@fluffy ~]$ ll -Z nothing -rw-rw-r--. 1 tim tim unconfined_u:object_r:user_home_t:s0 0 Dec 24 23:20 nothing But if I look at another file, one with special meaning that special rules have been created to handle it, you can see it has different contexts: -rw-------. 1 tim tim system_u:object_r:xdm_home_t:s0 9275 Dec 24 23:16 .xsession-errors And some other ones, as further examples: [tim@fluffy ~]$ ll -aZ .config/pulse/ total 12 drwx------. 2 tim tim unconfined_u:object_r:pulseaudio_home_t:s0 4096 Nov 20 07:37 . drwxr-xr-x. 32 tim tim unconfined_u:object_r:config_home_t:s0 4096 Dec 12 11:54 .. -rw-------. 1 tim tim unconfined_u:object_r:pulseaudio_home_t:s0 256 Jun 12 2022 cookie lrwxrwxrwx. 1 tim tim unconfined_u:object_r:pulseaudio_home_t:s0 23 Nov 20 07:37 f700387ca7ba4498a9edcb910aee3078-runtime -> /tmp/pulse- M5DMLD7vGw9D So, I suppose the questions about your file may be: Was your file named in an expected way, and stored in an expected location? And is it one that SELinux is supposed to know about? If it's an oddball unexpected thing, it might end up with generic SELinux contexts that label it as a naughty foreign file. If I look in /var/log/journal/long-hash-of-psuedo-random-numbers/, none of the files in there start with a dot or hash character. I wonder if it something's failing as it's creating a journal file, and mangling things? And without knowing it's contents, we can't guess at what's causing its creation. All the files in my /var/log/journal/j0rwsdf9u09usdf;oughj;/ filepath (I faked the hash, there) have this SELinux context: systemd-journal system_u:object_r:var_log_t:s0 If your problem file doesn't have that, you could try setting it to that, and see if you can read it. >From time to time the behaviours of our systems change, and SELinux gets updated with new rules to handle them. Sometimes there's a relabelling of files as part of those changes. Have you had any SELinux updates recently?
If I look at /var/log/journal/<long name> I get the following 4 files, where the 3rd filename matches the name in question if the ".#" and the suffix after journal are removed. I believe this is happening as part of boot or startup of KDE, I hadn't done anything when the issue occurred, and there hasn't been a recurrence of the message as I gave journal-offline the requested access.
system@19572e3c26de475f9eba598cb3968b08-0000000000000001-0005ef69a63e37c7.journal
system.journal
user-1000@7668ca11a5184a26bcf4a7c1858f9574-0000000000000a42-0005ef6078e3e7f0.journal
user-1000.journal
regards,
Steve
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue