Bug 972391
Summary: | SELinux is preventing /usr/bin/totem-video-thumbnailer from 'append' accesses on the unix_stream_socket unix_stream_socket. | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Matěj Cepl <mcepl> |
Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Michal Trunecka <mtruneck> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 7.0 | CC: | bnocera, ebenes, ksrot, mcepl, mgrepl, mmalik, mtruneck |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | abrt_hash:a96a137b78ec68b8d09f158593e52721549a021256f22b827de34c34b24a0db1 | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-06-16 08:18:21 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Matěj Cepl
2013-06-09 06:19:11 UTC
Does everything work correctly? (In reply to Miroslav Grepl from comment #2) > Does everything work correctly? I don't see any problems, but I am not sure what to look for. What file is it trying to write? This is probably nautilus wrongly detecting something as a video file and letting the thumbnailer loose on it. How do I reproduce this? (In reply to Bastien Nocera from comment #5) > How do I reproduce this? Unfortunately, I have no clue. Sealert warning just jumps on me from time to time. Even from studying the SELinux message I cannot decipher what is the concerned file. wycliff:x86_64# find /usr /var /home /tmp /etc /boot /root /srv -context '*xdm_t*' -print 2>/dev/null |tee /tmp/xdm_t-files.txt /tmp/.X0-lock /tmp/.ICE-unix /tmp/.ICE-unix/4546 /tmp/.X11-unix /tmp/.X11-unix/X0 wycliff:x86_64# Reassigning to selinux-policy for root causing. Even if the problem is with totem, nautilus or GStreamer, we cannot fix the bug unless we know how to cause it. The SELinux warning should show the full command-line path used to launch the triggering application to help root causing. #============= thumb_t ============== #!!!! This avc has a dontaudit rule in the current policy allow thumb_t xdm_t:unix_stream_socket append; Why are you adding a rule for this? In which circumstances would totem's video thumbnailer try to write to a socket in the xdm_t domain? We don't add the "allow" rule but we add the "dontaudit" rule. It means it won't be allowed and SELinux won't complain about it. Could we try and fix it instead? Is there a way to know why totem-video-thumbnailer required those permissions? Can I have an answer to comment 11? Not sure if I understand your question from comment 11. (In reply to Miroslav Grepl from comment #14) > Not sure if I understand your question from comment 11. You added a dontaudit rule which just hides the symptoms of the problem, instead of fixing the problem. How do I reproduce the problem so that we can effectively fix it instead of working around it? I have no idea how to reproduce it. # semodule -DB will turn off dontaudit rules. How does one reproduce the problem? I don't see how this problem can be marked as verified when there's no reproducer for it. Based on comment#0 it is a leaked file descriptor problem. The program which executed totem-video-thumbnailer leaked a fd. If the reporter does not know how to reproduce it I doubt we will find the cause. I tried following scenarios and the AVC didn't appear even if dontaudit rules were removed from active policy: * totem-video-thumbnailer under unconfined_u user in GNOME environment * totem-video-thumbnailer under staff_u user in GNOME environment Thumbnails were generated automatically and manual execution of totem-video-thumbnailer inside ~/.cache directory also worked well. This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request. |