Re: puzzling SELinux alert. [SOLVED]

On Wed, 2021-05-12 at 12:55 -0600, home user wrote: > That's as much of an answer as I can give. > This all applies to both the SELinux problems and what was addressed > in my "System Failure?" thread. DNF has a history command, which shows what was installed at various stages. If you type "dnf

Re: puzzling SELinux alert. [SOLVED]

On 5/11/21 2:05 PM, Eddie O'Connor wrote: I'm wondering?the ugrade/patches fixed it?would it have been fixed "sooner" if you had run the dnf upgrade sooner? or was it the "latest" upgrade/patch that did it?... On Tue, May 11, 2021, 12:35 PM home user >

Re: puzzling SELinux alert. [SOLVED]

I'm wondering?the ugrade/patches fixed it?would it have been fixed "sooner" if you had run the dnf upgrade sooner? or was it the "latest" upgrade/patch that did it?... On Tue, May 11, 2021, 12:35 PM home user wrote: > The SELinux alerts stopped on Thursday April 29. That would have

Re: puzzling SELinux alert. [SOLVED]

The SELinux alerts stopped on Thursday April 29.  That would have been when I did weekly patches ("dnf upgrade"). I also did weekly patches on Thursday, May 06. Since the alerts did not start showing up again, I'm now confident they're really fixed. I've added a comment to

Re: puzzling SELinux alert.

This morning, I was able to get SELinux alerts when running totem-video-thumbnailer. I submitted a bug. Here's the link: "https://bugzilla.redhat.com/show_bug.cgi?id=1951668;. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe

Re: puzzling SELinux alert.

On 4/16/21 8:51 PM, Tim via users wrote: On Fri, 2021-04-16 at 11:27 -0500, Roger Heflin wrote: given a video file and an png file to output it fails on my system also (and that is with selinux as permissive and as root, so it seems to have many issues and is simply broken in most if not all

Re: puzzling SELinux alert.

On Fri, 2021-04-16 at 11:27 -0500, Roger Heflin wrote: > given a video file and an png file to output it fails on my system > also (and that is with selinux as permissive and as root, so it seems > to have many issues and is simply broken in most if not all use > cases), and I don't know that I

Re: puzzling SELinux alert.

On 4/16/21 10:27 AM, Roger Heflin wrote: That matches what Ed had called out that it was a GL* command. I guess that also tells you why you did not notice the failing.. given a video file and an png file to output it fails on my system also (and that is with selinux as permissive and as root,

Re: puzzling SELinux alert.

That matches what Ed had called out that it was a GL* command. I guess that also tells you why you did not notice the failing.. given a video file and an png file to output it fails on my system also (and that is with selinux as permissive and as root, so it seems to have many issues and is

Re: puzzling SELinux alert.

On 4/16/21 5:41 AM, Roger Heflin wrote: It seems to be running /usr/bin/totem-video-thumbnailer" so would be something attempting to create a thumbnail for the file if it is a video. It has an extension of .mkv so it thinks it is a video file or is it something else? It is a video file. the

Re: puzzling SELinux alert.

It seems to be running /usr/bin/totem-video-thumbnailer" so would be something attempting to create a thumbnail for the file if it is a video. It has an extension of .mkv so it thinks it is a video file or is it something else? the command was: /usr/bin/totem-video-thumbnailer -s 128

Re: puzzling SELinux alert.

On 4/15/21 8:27 PM, home user wrote: The grep for the process ID "2636" found lines. Correction: The grep for the process ID "2636" found 34361 lines. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to

Re: puzzling SELinux alert.

On 4/15/21 3:57 PM, Roger Heflin wrote: (also responding to Samuel) Google drive probably. The first few lines should tell you what process it was starting. I really usually only look at filesystem type calls as those are usually the most valuable for something like this. open, unlink

Re: puzzling SELinux alert.

On 4/15/21 9:48 AM, home user wrote: Based on time stamps, I found that the process ID for Test B was 2636. I did: bash.17[~]: grep 2636 caja.out > grep2636.out The resulting file is over 34000 lines long.  How can I pare this down?  What should I put on the google drive for y'all to view?

Re: puzzling SELinux alert.

Google drive probably. The first few lines should tell you what process it was starting. I really usually only look at filesystem type calls as those are usually the most valuable for something like this. open, unlink (remove), stat (get info like ls shows), and say rename or renameat. A lot

Re: puzzling SELinux alert.

(responding to multiple posts) As Ed requested, this morning I signed in to "GNOME on Xorg" first. My tests were as follows. Test A. 1. Using the command line in a terminal, I downloaded a Chinese music video. The resulting file has a name made of traditional (Taiwan) Chinese characters.

Re: puzzling SELinux alert.

On 4/14/21 4:43 PM, Ed Greshko wrote: On 15/04/2021 05:57, home user wrote: The desktop menu at login has 4 GNOME entries: GNOME GNOME GNOME Classic GNOME on Xorg I usually use the first GNOME. Side question: What's the difference between the first two entries? So, tomorrow, start by using

Re: puzzling SELinux alert.

On 15/04/2021 05:57, home user wrote: Is your desktop "GNOME" or "GNOME on Xorg"? The desktop menu at login has 4 GNOME entries: GNOME GNOME GNOME Classic GNOME on Xorg I usually use the first GNOME. Side question: What's the difference between the first two entries? I don't know why you'd

Re: puzzling SELinux alert.

On 4/14/21 3:46 PM, Roger Heflin wrote: really just start caja from the terminal with strace -o caja.out -f `which caja` do what you normally do and exit. then grep pid caja.out and that will should tell you what executable that pid was and some of what it did. That will produce an .out file

Re: puzzling SELinux alert.

On 4/14/21 3:18 PM, Ed Greshko wrote: Is your desktop "GNOME" or "GNOME on Xorg"? The desktop menu at login has 4 GNOME entries: GNOME GNOME GNOME Classic GNOME on Xorg I usually use the first GNOME. Side question: What's the difference between the first two entries? Which ever one it is,

Re: puzzling SELinux alert.

really just start caja from the terminal with strace -o caja.out -f `which caja` do what you normally do and exit. then grep pid caja.out and that will should tell you what executable that pid was and some of what it did. That will produce an .out file that contains all of the pid's and what

Re: puzzling SELinux alert.

On 15/04/2021 05:06, home user wrote: On 4/14/21 12:52 PM, Ed Greshko wrote: On 15/04/2021 00:33, home user wrote: I tried that using "ps -ef | grep [pid]".  The only hit was the ps command  itself. It is not clear to me that you did this immediately after getting the alert. 1. I launched

Re: puzzling SELinux alert.

On 4/14/21 1:50 PM, Roger Heflin wrote: He might want to run a strace -o appname.out -f And then do the ausearch and we should be able to see what what the pid was doing and/or what executable it was. What options would you find most helpful? ___

Re: puzzling SELinux alert.

On 4/14/21 12:52 PM, Ed Greshko wrote: On 15/04/2021 00:33, home user wrote: I tried that using "ps -ef | grep [pid]".  The only hit was the ps command itself. It is not clear to me that you did this immediately after getting the alert. 1. I launched caja from the gnome activities dash.

Re: puzzling SELinux alert.

He might want to run a strace -o appname.out -f And then do the ausearch and we should be able to see what what the pid was doing and/or what executable it was. On Wed, Apr 14, 2021 at 1:52 PM Ed Greshko wrote: > > On 15/04/2021 00:33, home user wrote: > > I tried that using "ps -ef | grep

Re: puzzling SELinux alert.

On 15/04/2021 00:33, home user wrote: I tried that using "ps -ef | grep [pid]".  The only hit was the ps command  itself. It is not clear to me that you did this immediately after getting the alert. According to the ausearch_out the PID is different at each instance of an alert.  So, it is

Re: puzzling SELinux alert.

On 4/14/21 1:26 AM, Ed Greshko wrote: On 14/04/2021 11:41, home user wrote: Last night, in ".bash_profile", I commented out the block of code that launches xeyes, and shut down for the night. This morning, I booted up and logged in, No xeyes. I downloaded a Chinese music video. I then

Re: puzzling SELinux alert.

On 14/04/2021 11:41, home user wrote: Tomorrow morning, I will try the no-xeyes test that you suggest. Ignoring the problem is tempting, but I don't want to give up too easily. Well, pardon me for saying I find that last observation somewhat narrow in scope.  :-) :-) That being

Re: puzzling SELinux alert.

On 4/13/21 5:20 PM, Ed Greshko wrote: Long zoom meeting done; now I'm back to this. memfd refers to "Memory File Descriptor".  The file in question exists only in RAM and is a temporary file at that. Command such as "restorecon" are useless for this. ok. I'm guessing it may be caused not

Re: puzzling SELinux alert.

On 4/13/21 5:06 PM, Roger Heflin wrote: sestatus will show the current status. if enforcing then something may not be functioning as designed. if permissive then it will report it is blocking when it is not, and if you set it enforcing then something would probably break. if you set it

Re: puzzling SELinux alert.

On 14/04/2021 01:40, home user wrote: At least 3 times in the past few days I've seen the same SELinux alert.  I put the text of the details in the attached file "alerts.txt".  All 3 occurrences were while using caja to rename or delete a file, though it does not happen every time I rename or

Re: puzzling SELinux alert.

sestatus will show the current status. if enforcing then something may not be functioning as designed. if permissive then it will report it is blocking when it is not, and if you set it enforcing then something would probably break. if you set it permissive at one time then it will stay set

Re: puzzling SELinux alert.

On 4/13/21 2:24 PM, Roger Heflin wrote: Are you running permissive or enforcing? > if permissive then it does not block anything, but says it is blocking if enforcing it is blocking something, though it may be a pointless/useless interface feature of some sort that does not matter, and does not

Re: puzzling SELinux alert.

Are you running permissive or enforcing? if permissive then it does not block anything, but says it is blocking if enforcing it is blocking something, though it may be a pointless/useless interface feature of some sort that does not matter, and does not really affect functionality. And it might

Re: puzzling SELinux alert.

On 4/13/21 12:48 PM, Roger Heflin wrote: I see a lot of /memfd: in lsof it appears to be anonymous files (ie temp files). I am going to guess memfd is memory file descriptor, ie a temp file created in memory. Usually they are going to not actually exist anywhere in a fs. And generally the

Re: puzzling SELinux alert.

I see a lot of /memfd: in lsof it appears to be anonymous files (ie temp files). I am going to guess memfd is memory file descriptor, ie a temp file created in memory. Usually they are going to not actually exist anywhere in a fs. And generally the app that opens/creates them is the app that

puzzling SELinux alert.

At least 3 times in the past few days I've seen the same SELinux alert.  I put the text of the details in the attached file "alerts.txt".  All 3 occurrences were while using caja to rename or delete a file, though it does not happen every time I rename or delete a file in caja.  These alerts