5:33 p.m.
Hi,
How do I identify what file
.#user-1000@7668ca11a5184a26bcf4a7c1858f9574-0000000000000a42-0005ef6078e3e7f0.journalc7d37931ac52343c
is? The component before the "@" in the file name looks like the file
may be relative to my userid. I'm using an F37 system upgraded from F36.
Also how do I determine why "journal-offline" would be denied
"relabelfrom" access on that file by selinux?
I have given journal-offline the access attempted (I know this
might be problematic given the questions I'm asking), but I'm also
trying to determine why it happened in the first place, and whether or
not, as indicated in the error details, I should be raising this as a
bug. The timing of this error seems to be indicating it occurred during
boot this morning, and the audit message is indicating the file is
potentially on device "sdd1", which is potentially my fedora root
partition, which doesn't have /boot nor /boot/efi as they are on another
device, and if it is the root device, that device is a btrfs logical
device and both the physical and logical devices have the same label.
regards,
Steve
7:27 p.m.
On 12/23/22 15:33, Stephen Morris wrote:
Hi,
How do I identify what file
.#user-1000@7668ca11a5184a26bcf4a7c1858f9574-0000000000000a42-0005ef6078e3e7f0.journalc7d37931ac52343c
is? The component before the "@" in the file name looks like the file may be
relative to my userid. I'm using an F37 system upgraded from F36.
Also how do I determine why "journal-offline" would be denied
"relabelfrom" access on that file by selinux?
I have given journal-offline the access attempted (I know this
might be problematic given the questions I'm asking), but I'm also
trying to determine why it happened in the first place, and whether or
not, as indicated in the error details, I should be raising this as a
bug. The timing of this error seems to be indicating it occurred during
boot this morning, and the audit message is indicating the file is
potentially on device "sdd1", which is potentially my fedora root
partition, which doesn't have /boot nor /boot/efi as they are on another
device, and if it is the root device, that device is a btrfs logical
device and both the physical and logical devices have the same label.
That looks like a temporary file of some sort. It would most likely be
in /var/log/journal/<some kind of id>/.
I don't think you would need to modify the selinux config for that.
Either ignore it or delete the file if the message keeps happening.
7:28 p.m.
On 12/23/22 17:27, Samuel Sieb wrote:
On 12/23/22 15:33, Stephen Morris wrote:
> Hi,
> How do I identify what file
>
.#user-1000@7668ca11a5184a26bcf4a7c1858f9574-0000000000000a42-0005ef6078e3e7f0.journalc7d37931ac52343c
is? The component before the "@" in the file name looks like the file may be
relative to my userid. I'm using an F37 system upgraded from F36.
> Also how do I determine why "journal-offline" would be denied
> "relabelfrom" access on that file by selinux?
> I have given journal-offline the access attempted (I know this
> might be problematic given the questions I'm asking), but I'm also
> trying to determine why it happened in the first place, and whether or
> not, as indicated in the error details, I should be raising this as a
> bug. The timing of this error seems to be indicating it occurred
> during boot this morning, and the audit message is indicating the file
> is potentially on device "sdd1", which is potentially my fedora root
> partition, which doesn't have /boot nor /boot/efi as they are on
> another device, and if it is the root device, that device is a btrfs
> logical device and both the physical and logical devices have the same
> label.
That looks like a temporary file of some sort. It would most likely be
in /var/log/journal/<some kind of id>/.
The id is the value from /etc/machine-id.
8:35 p.m.
On 24/12/22 12:28, Samuel Sieb wrote:
On 12/23/22 17:27, Samuel Sieb wrote:
> On 12/23/22 15:33, Stephen Morris wrote:
>> Hi,
>> How do I identify what file
>>
.#user-1000@7668ca11a5184a26bcf4a7c1858f9574-0000000000000a42-0005ef6078e3e7f0.journalc7d37931ac52343c
>> is? The component before the "@" in the file name looks like the
>> file may be relative to my userid. I'm using an F37 system upgraded
>> from F36.
>> Also how do I determine why "journal-offline" would be denied
>> "relabelfrom" access on that file by selinux?
>> I have given journal-offline the access attempted (I know this
>> might be problematic given the questions I'm asking), but I'm also
>> trying to determine why it happened in the first place, and whether
>> or not, as indicated in the error details, I should be raising this
>> as a bug. The timing of this error seems to be indicating it
>> occurred during boot this morning, and the audit message is
>> indicating the file is potentially on device "sdd1", which is
>> potentially my fedora root partition, which doesn't have /boot nor
>> /boot/efi as they are on another device, and if it is the root
>> device, that device is a btrfs logical device and both the physical
>> and logical devices have the same label.
>
> That looks like a temporary file of some sort. It would most likely
> be in /var/log/journal/<some kind of id>/.
The id is the value from /etc/machine-id.
I've just checked
/var/log/journal/<some kind of id>/ on a freshly warm
booted system, and the user file listed above is still there albeit
without the .# prefix and without the suffix after journal, so having
given journal the relabelfrom access, it now looks to me like it is
trying to rename the above file to remove the prefix and suffix, which
it now can do (I'm only surmising that is what is happening as I don't
understand what the message meant).
If that is what is happening why does journal-offline not have the
access by default and should it be reported? There is a similarly named
file in the folder with "system" before the "@", which presumably
journal-offline has no issues with, so why should it have issues with
the files created for the logging in user?
regards,
Steve
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
10:41 p.m.
On Sat, 2022-12-24 at 10:33 +1100, Stephen Morris wrote:
How do I identify what file
.#user-1000@7668ca11a5184a26bcf4a7c1858f9574-0000000000000a42-0005ef6078e3e7f0.journalc7d37931ac52343c
is?
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.
--
uname -rsvp
Linux 3.10.0-1160.81.1.el7.x86_64 #1 SMP Fri Dec 16 17:29:43 UTC 2022 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
5:23 a.m.
On 24/12/22 15:41, Tim via users wrote:
On Sat, 2022-12-24 at 10:33 +1100, Stephen Morris wrote:
> How do I identify what file
>
.#user-1000@7668ca11a5184a26bcf4a7c1858f9574-0000000000000a42-0005ef6078e3e7f0.journalc7d37931ac52343c
> is?
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.
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?
regards,
Steve
7:11 a.m.
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
6:46 p.m.
On 25/12/22 00:11, Tim via users wrote:
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?
There may have been updates to Selinux installed via "dnf upgrade",
which I have down quite a few times.
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
477
days inactive
483
days old
7 comments
3 participants
participants (3)
-
Samuel Sieb -
Stephen Morris -
Tim