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 confuse me. There is no directory "/memdf:"...
-bash.1[~]: cd /
-bash.2[/]: ls -a
. boot etc lib64 mnt root srv system-upgrade usr
.. .cache home lost+found opt run sys system-upgrade-root var
bin dev lib media proc sbin sysroot tmp
-bash.3[/]: ls -a /memfd*
ls: cannot access '/memfd*': No such file or directory
-bash.4[/]:
Also, the directory name (ending with a colon?) looks fishy. Further,
the filename ".nvidia_drv.XXXXXX" looks fishy (but "legal").
The instruction does not work:
-bash.4[/]: /sbin/restorecon -v /memfd:/.nvidia_drv.XXXXXX (deleted)
-bash: syntax error near unexpected token `('
-bash.4[/]:
-bash.5[/]: /sbin/restorecon -v /memfd:/.nvidia_drv.XXXXXX
/sbin/restorecon: SELinux: Could not get canonical path for
/memfd:/.nvidia_drv.XXXXXX restorecon: No such file or directory.
-bash.6[/]:
I gather that a directory and or file (whatever its name really is) are
missing?
How do I fix this?
SELinux is preventing gstglcontext from write access on the file /memfd:/.nvidia_drv.XXXXXX (deleted).
***** Plugin restorecon (99.5 confidence) suggests ************************
If you want to fix the label.
/memfd:/.nvidia_drv.XXXXXX (deleted) default label should be default_t.
Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly.
Do
# /sbin/restorecon -v /memfd:/.nvidia_drv.XXXXXX (deleted)
***** Plugin catchall (1.49 confidence) suggests **************************
If you believe that gstglcontext should be allowed write access on the .nvidia_drv.XXXXXX (deleted) file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'gstglcontext' --raw | audit2allow -M my-gstglcontext
# semodule -X 300 -i my-gstglcontext.pp
Additional Information:
Source Context unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023
Target Context system_u:object_r:xserver_tmpfs_t:s0
Target Objects /memfd:/.nvidia_drv.XXXXXX (deleted) [ file ]
Source gstglcontext
Source Path gstglcontext
Port <Unknown>
Host coyote
Source RPM Packages
Target RPM Packages
SELinux Policy RPM selinux-policy-targeted-3.14.6-36.fc33.noarch
Local Policy RPM selinux-policy-targeted-3.14.6-36.fc33.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name coyote
Platform Linux coyote 5.11.11-200.fc33.x86_64 #1 SMP Tue
Mar 30 16:53:32 UTC 2021 x86_64 x86_64
Alert Count 14
First Seen 2021-04-10 20:54:09 MDT
Last Seen 2021-04-13 10:52:06 MDT
Local ID 97b55286-0131-46f4-86ad-481e32b4563f
Raw Audit Messages
type=AVC msg=audit(1618332726.288:964): avc: denied { write } for pid=129605 comm="gstglcontext" path=2F6D656D66643A2F2E6E76696469615F6472762E585858585858202864656C6574656429 dev="tmpfs" ino=1025 scontext=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:xserver_tmpfs_t:s0 tclass=file permissive=0
Hash: gstglcontext,thumb_t,xserver_tmpfs_t,file,write
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
