On 4/13/21 12:48 PM, Roger Heflin wrote: I've attached the output of "lsof | grep "/memfd:/.nvidia"". When I ran that, caja, a terminal, and xeyes were running. When I ran the renames and deletes in caja, they all worked properly even though I received the SELinux alerts in some cases. Would that have been so if caja was lacking SELinux permissions?

On 4/13/21 2:24 PM, Roger Heflin wrote: When I first installed this system 8 years ago, SELinux was there by default. My knowledge of it is very high level and superficial. I don't recall ever setting anything either of those 2 ways; I'm running whatever the default is. I don't know the answer to your question, nor do I know how to find out. I do need to find a better way to reproduce the problem and test fixes (like the restorecon command you suggested). Currently, it seems I get the problem only the first 1 or 2 times per login, per boot, or per day (I haven't yet figured out which). I also want to figure out if the problem is limited to caja, or if "files" also has the problem.

On 4/13/21 5:06 PM, Roger Heflin wrote: It is "enforcing": bash.1[~]: su - Password: -bash.1[~]: sestatus -v SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 33 Process contexts: Current context: unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 Init context: system_u:system_r:init_t:s0 File contexts: Controlling terminal: unconfined_u:object_r:user_devpts_t:s0 /etc/passwd system_u:object_r:passwd_file_t:s0 /etc/shadow system_u:object_r:shadow_t:s0 /bin/bash system_u:object_r:shell_exec_t:s0 /bin/login system_u:object_r:login_exec_t:s0 /bin/sh system_u:object_r:bin_t:s0 -> system_u:object_r:shell_exec_t:s0 /sbin/agetty system_u:object_r:getty_exec_t:s0 /sbin/init system_u:object_r:bin_t:s0 -> system_u:object_r:init_exec_t:s0 /usr/sbin/sshd system_u:object_r:sshd_exec_t:s0 /lib/libc.so.6 system_u:object_r:lib_t:s0 -> system_u:object_r:lib_t:s0 /lib/ld-linux.so.2 system_u:object_r:lib_t:s0 -> system_u:object_r:ld_so_t:s0 -bash.2[~]:

On 4/13/21 5:20 PM, Ed Greshko wrote: Long zoom meeting done; now I'm back to this. ok. You remember correctly. I started out with the proprietary driver 8 years ago. 1 or 2 years later, as advised by this list, I switched to the kmod? package(s?) from rpmfusion. The rpmfusion stuff was installed the way members of this list instructed. I see the rpmfusion stuff patched during over half of my weekly patches. I don't know if any of this helps, but here goes: * The problem started after upgrading to f33. * I have not noticed any problems with xeyes. * The sequence of steps leading to the alerts is: 1. Using the command line in a terminal, download a Chinese music video. The resulting file has a name made of traditional (Taiwan) Chinese characters. 2. Launch caja. 3. Use caja to rename the file to something with all ASCII characters. 4. Use caja to launch the file for viewing. I think it's launching VLC for that. 5. View the file and, using vim in a terminal, make study notes. 6. In caja, delete the file. In caja, for each file, there is a small icon, the name of the file, and meta-data for the file. In the case of video files, that icon is an image, a frame from the video. The factors that have been occurring to me are the traditional Chinese characters and the image icons. But why only the first time in a login session? That's what most puzzles me. 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 toooooo easily.

On 4/14/21 1:26 AM, Ed Greshko 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 launched caja. Before I tried doing anything in it, a SELinux alert appeared, So it seems that xeyes has nothing to do with this problem. I tried launching "files". I did not see any SELinux alerts. After doing the above described test, I ran the command to get everything from the start of yesterday. I posted the results in a simple text file on the google drive. Here's the link: "https://drive.google.com/file/d/1-BSwKWu_Mi3CozfLRi2dQmzPndi3HHqj/view?usp=sharing" I tried that using "ps -ef | grep [pid]". The only hit was the ps command itself. I still have the SELinux alert details for the past several days. I can post anything that you want to see, if that would help.

He might want to run a strace -o appname.out -f <startupappgettingtheerrorandoptions> 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 <ed.greshko(a)greshko.com&gt; 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. > > According to the ausearch_out the PID is different at each instance of an alert. So, it is possible that > whatever process produced the alert has exited or died after the series of alerts. > > -- > Remind me to ignore comments which aren't germane to the thread. > > _______________________________________________ > 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 on the list, report it: https://pagure.io/fedora-infrastructure

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 those pids were and some of what they did. On Wed, Apr 14, 2021 at 4:09 PM home user <mattisonw(a)comcast.net&gt; wrote: > > On 4/14/21 1:50 PM, Roger Heflin wrote: > > He might want to run a strace -o appname.out -f > > <startupappgettingtheerrorandoptions> > > > > 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? > _______________________________________________ > 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 on the list, report it: https://pagure.io/fedora-infrastructure

On 4/14/21 12:52 PM, Ed Greshko wrote: 1. I launched caja from the gnome activities dash. The caja GUI displays. 2. The SELinux alert shows up. 3. I trackball over to the alert and click the Details button. 4. The Details window comes up, I trackball over to it, I make it bigger. 5. I scroll down and look for the pid. 6. I trackball over to the terminal and enter the ps command. Steps 2 thru 6 do take several seconds, maybe up to a minute. That's as "immediate" as I can do. I agree.

On 4/14/21 3:18 PM, Ed Greshko 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? Unable to determine! I logged out, and then logged back in without changing the desktop. I launched Files. No alert. I launched caja. No alert. I shut down and the booted up and logged in with GNOME. I launched Files. No alert. I launched caja. No alert. I shut down and booted up and logged in with GNOME. I launched caja. No alert. I shut down and booted up and logged in with GNOME on Xorg. I launched caja. No alert. Yesterday evening, I suspected that the problem can be reproduced only once per day. That's why I said last night that I would test this morning. The above test sequence strengthens my suspicion, but does not prove, that this problem can be reproduced only once per day (not once per login session, not once per boot session). I can't (yet) rule out that the open terminal, Thunderbird, or "youtube-dl" somehow play into this. I'm also still trying to determine whether this problem is unique to caja, or if Files has the same problem. I'll try your suggested test again tomorrow morning.

On 4/14/21 4:43 PM, Ed Greshko wrote: Done as requested. Regardless of whether I log in using the first, third, or fourth GNOME choice, I get: bash.1[~]: env | grep -i wayland bash.2[~]: I did not try GNOME Classic. What command did you use for the above? It looks like "ps" output, but when I try, I get these: bash.8[~]: ps -ef | grep -i earlyoom weilian+ 2823 2705 0 09:53 pts/0 00:00:00 grep --color=auto -i earlyoom bash.9[~]: ps -aux | grep -i earlyoom weilian+ 2829 0.0 0.0 221564 840 pts/0 S+ 09:53 0:00 grep --color=auto -i earlyoom bash.10[~]: ps -al | grep -i earlyoom bash.11[~]: I did also try logging in to plasma with wayland. After entering my credentials, the screens went black. After 2 minutes, I hit the hard reset and rebooted. Through 8 years of weekly patches and semi-annual upgrades, I've never done anything to block or disable wayland. Shouldn't it have been automatically installed somewhere in those 8 years? What did I do wrong or not do? I'll report caja testing in my next message.

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 of stats always fail as it is used to see if various things exist here or there. Basic it loads an executable, lots of setup of that executable then toward the end is the real work the program does. On a mv strace I get 117 lines with the executable and options at the top, a bunch of loading of libs and stuff for executable then 10 lines from the bottom is the actual rename, and the exit of the program. On Thu, Apr 15, 2021 at 11:49 AM home user <mattisonw(a)comcast.net&gt; wrote: > > (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. > 2. I launched caja. > A SELinux alert pops up. > 3. I used caja to rename the file to something with all ASCII characters. > A Selinux alert pops up. > Steps 2 and 3 were done a few times. For step 2, the SELinux alert > occurs the first time only. > For step 3, the SELinux alert occurs every time. > > Then Test B. > 1. I did "strace -o caja.out -f /usr/bin/caja". > 2. I used caja to rename a file to something with all ASCII characters. > A Selinux alert pops up. > 3. I closed caja by clicking the little x in the upper right corner of > the GUI. > > Then Test C. > 1. I launched Files. > 2. I used Files to rename a file to something with all ASCII characters. > 3. I closed Files by clicking the little x in the upper right corner of > the GUI. > No SELinux alerts. > > Then Test D. > 1. I launched caja. > 2. I used caja to rename a file to something with all ASCII characters. > 3. I closed caja by clicking the little x in the upper right corner of > the GUI. > No SELinux alerts. > > Files seems to do something that prevents any further SELinux alerts > from caja for the rest of the day. > > I did: > bash.2[~]: su - > Password: > -bash.1[~]: ausearch -c gstglcontext -ts today > ausearch_Thurs.txt > -bash.2[~]: vi ausearch_Thurs.txt > 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? > _______________________________________________ > 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 on the list, report it: https://pagure.io/fedora-infrastructure

On 4/15/21 8:27 PM, home user wrote: Correction: The grep for the process ID "2636" found 34361 lines.

On 4/16/21 5:41 AM, Roger Heflin wrote: It is a video file. bash.2[~]: totem-video-thumbnailer KhongWeeHo_20160327.mkv KhongWeeHo_20160327.png X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 151 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Value in failed request: 0x0 Serial number of failed request: 63 Current serial number in output stream: 64 bash.3[~]: I also tried an mp4 video file that I have. Same result.

On 4/16/21 10:27 AM, Roger Heflin wrote: What I think you're saying, and my impression even apart from your post, is that we can't realistically solve this SELinux alert problem. This problem really has had me baffled. The SELinux alerts seem to be false alarms; caja does what I want to do, and I can do those things other ways also. So I'm inclined to go with what Ed said Tuesday: For what it's worth: * I saw no SELinux alerts when trying totem-video-thumbnailer in the command line. I forgot to mention this in this morning's post. * I found this morning that SELinux alerts can show up when doing file renaming after having run Files in the same login session. So Files does not stop further caja SELinux alerts. * I patched my workstation (dnf upgrade) yesterday. > On Fri, Apr 16, 2021 at 10:27 AM home user <mattisonw(a)comcast.net&gt; wrote: >> >> 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 command was: >>> /usr/bin/totem-video-thumbnailer -s 128 file:///home/bill/KhongWe"..., >>> "/tmp/.mate_desktop_thumbnail.19V" >>> >>> It truncated the filenames, but you could test run the command and see >>> what it does from the command line. The first filename is the input >>> file, the 2nd one is the output of the thumbnail. >> >> bash.2[~]: totem-video-thumbnailer KhongWeeHo_20160327.mkv >> KhongWeeHo_20160327.png >> X Error of failed request: BadValue (integer parameter out of range for >> operation) >> Major opcode of failed request: 151 (GLX) >> Minor opcode of failed request: 3 (X_GLXCreateContext) >> Value in failed request: 0x0 >> Serial number of failed request: 63 >> Current serial number in output stream: 64 >> bash.3[~]: >> >> I also tried an mp4 video file that I have. Same result.

On 4/16/21 8:51 PM, Tim via users wrote: My experience is that sometimes I do get images from the video, and sometimes I just get a right-pointing arrow centered in an old-fashioned CRT TV screen. I haven't been able to discern a pattern as to when I get which. I do notice that the odds of getting pictures is better when the display is in grid mode rather than list mode.

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".

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 <mattisonw(a)comcast.net&gt; wrote:

On Wed, 2021-05-12 at 12:55 -0600, home user wrote: DNF has a history command, which shows what was installed at various stages. If you type "dnf history", you get a table of events. Then you can use "dnf info" followed by the entry number you're interested in, you'll see what packages were installed/updated that time. -- uname -rsvp Linux 3.10.0-1160.25.1.el7.x86_64 #1 SMP Wed Apr 28 21:49:45 UTC 2021 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.