Re: Updating SELinux alert browser's Bugzilla API key

Sam Varshavchik wrote: > How do I update setroubleshoot's API key, the one it uses > to create bugzilla bugs. My key has expired, and I can't > figure out how to update it. > > The "Report Bug" option just goes through the motions, and > fails because its API key expired. A very exhaustive > searc

Updating SELinux alert browser's Bugzilla API key

How do I update setroubleshoot's API key, the one it uses to create bugzilla bugs. My key has expired, and I can't figure out how to update it. The "Report Bug" option just goes through the motions, and fails because its API key expired. A very exhaustive search in setroubleshoot was unable t

Re: SELinux alert

> > On 2022-07-12 01:02, Patrick Dupre wrote: > > I do not how to deal wit this issue: in fc34 and fc36. > > > > SELinux security alert recommend the following: > > > > You need to change the label on /var/usermin/miniserv.pid > > # semanage fcontext -a -t FILE_TYPE '/var/usermin/miniserv.pid' > >

Re: SELinux alert

On 2022-07-12 01:02, Patrick Dupre wrote: I do not how to deal wit this issue: in fc34 and fc36. SELinux security alert recommend the following: You need to change the label on /var/usermin/miniserv.pid # semanage fcontext -a -t FILE_TYPE '/var/usermin/miniserv.pid' where FILE_TYPE is one of th

SELinux alert

Hello, I do not how to deal wit this issue: in fc34 and fc36. SELinux security alert recommend the following: You need to change the label on /var/usermin/miniserv.pid # semanage fcontext -a -t FILE_TYPE '/var/usermin/miniserv.pid' where FILE_TYPE is one of the following: NetworkManager_etc_rw_t

SELinux alert

Hello, I have the recommendation You need to change the label on /var/usermin/miniserv.pid # semanage fcontext -a -t FILE_TYPE '/var/usermin/miniserv.pid' where FILE_TYPE is one of the following: NetworkManager_etc_rw_t, NetworkManager_etc_t, NetworkManager_exec_t, etc... a long list of FILE_TYPE

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 h

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 > wro

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 been

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 "https://bugzilla.r

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 sen

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 use

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 hav

Re: puzzling SELinux alert.

ally 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: > But if you're not having any problems

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 simpl

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 file:///home

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 users-le..

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 (remove

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? Th

Re: puzzling SELinux alert.

gt; 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

Re: puzzling SELinux alert.

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 t

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 t

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, cou

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 tho

Re: puzzling SELinux alert.

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 o

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? ___ us

Re: puzzling SELinux alert.

ities 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 comman

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 [pid

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 po

Re: puzzling SELinux alert.

o. 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. Your AVC you posted was type=AVC msg=audit(1618332726.288:964): a

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 said

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 by

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 permiss

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 t

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 perm

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 app

Re: puzzling SELinux alert.

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.

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.

Re: SELinux alert

On 09/24/2015 04:10 PM, Beartooth wrote: > > The SELinux troubleshooter is telling me (for the first time > afaik) that something called console-kit-dae has tried five times to > write to /var/lib/dbus. > > Details : > > > SELinux is preventing console-kit-dae from write access o

Re: SELinux alert

On 09/24/2015 07:10 AM, Beartooth wrote: What should I do?? File a bug, and consider adding the local policy to prevent further alerts. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedor

SELinux alert

The SELinux troubleshooter is telling me (for the first time afaik) that something called console-kit-dae has tried five times to write to /var/lib/dbus. Details : SELinux is preventing console-kit-dae from write access on the directory / var/lib/dbus. * Plugin catchall

Re: new selinux alert on F19

On Mon, Jun 17, 2013 at 11:48:45AM -0400, Daniel J Walsh wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 06/15/2013 12:27 PM, Fred Smith wrote: > > Hi all! > > > > I've been running F19 (alpha and now beta) on my Acer Aspire One D255E > > netbook for a few weeks now. > > > > jus

Re: new selinux alert on F19

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/15/2013 12:27 PM, Fred Smith wrote: > Hi all! > > I've been running F19 (alpha and now beta) on my Acer Aspire One D255E > netbook for a few weeks now. > > just today when I booted up I got this alert I've not gotten before. I know > how to te

Re: new selinux alert on F19

On Sun, Jun 16, 2013 at 12:43:44AM +0800, Ed Greshko wrote: > On 06/16/13 00:27, Fred Smith wrote: > > Hi all! > > > > I've been running F19 (alpha and now beta) on my Acer Aspire One D255E > > netbook for a few weeks now. > > > > just today when I booted up I got this alert I've not gotten before.

Re: new selinux alert on F19

On 06/16/13 00:27, Fred Smith wrote: > Hi all! > > I've been running F19 (alpha and now beta) on my Acer Aspire One D255E > netbook for a few weeks now. > > just today when I booted up I got this alert I've not gotten before. > I know how to teach selinux not to alert for that, but I don't know if

new selinux alert on F19

Hi all! I've been running F19 (alpha and now beta) on my Acer Aspire One D255E netbook for a few weeks now. just today when I booted up I got this alert I've not gotten before. I know how to teach selinux not to alert for that, but I don't know if it's an action that SHOULD be allowed or not. It