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? -- NB: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the list. The following system info data is generated fresh for each post: uname -rsvp Linux 6.0.10-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Nov 26 16:53:11 UTC 2022 x86_64 _______________________________________________ users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
