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