Description of problem: SELinux is preventing /usr/bin/evince-thumbnailer from 'write' accesses on the file .mate_desktop_thumbnail.6IWV5W. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that evince-thumbnailer should be allowed write access on the .mate_desktop_thumbnail.6IWV5W 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: # grep evince-thumbnai /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 Target Context unconfined_u:object_r:user_home_t:s0 Target Objects .mate_desktop_thumbnail.6IWV5W [ file ] Source evince-thumbnai Source Path /usr/bin/evince-thumbnailer Port <Unknown> Host (removed) Source RPM Packages evince-3.8.3-2.fc19.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-74.10.fc19.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.11.6-200.fc19.x86_64 #1 SMP Fri Oct 18 22:34:18 UTC 2013 x86_64 x86_64 Alert Count 35 First Seen 2013-10-20 14:00:31 EDT Last Seen 2013-10-30 10:42:55 EDT Local ID e413c709-9ad4-4a74-9a99-5d2e0dcffb39 Raw Audit Messages type=AVC msg=audit(1383144175.572:1028): avc: denied { write } for pid=27502 comm="evince-thumbnai" name=".mate_desktop_thumbnail.6IWV5W" dev="dm-5" ino=167207 scontext=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file type=SYSCALL msg=audit(1383144175.572:1028): arch=x86_64 syscall=open success=no exit=EACCES a0=2488e50 a1=241 a2=1b6 a3=0 items=0 ppid=19848 pid=27502 auid=1001 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001 egid=1001 sgid=1001 fsgid=1001 ses=37 tty=(none) comm=evince-thumbnai exe=/usr/bin/evince-thumbnailer subj=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 key=(null) Hash: evince-thumbnai,thumb_t,user_home_t,file,write Additional info: reporter: libreport-2.2.0 hashmarkername: setroubleshoot kernel: 3.13.7-200.fc20.x86_64 type: libreport Potential duplicate: bug 838186
You will need to fix labeling $ restorecon -R -v ~ If it does not help, please reopen the bug. Thank you.
(In reply to Miroslav Grepl from comment #1) > You will need to fix labeling > > $ restorecon -R -v ~ I seem to get this response to these selinux violation bugs quite often. Why I do have to do this over and over again? Rather than applying a really big hammer such as relabeling a whole (large, with many subdirs) directory tree, why not try to investigate why this needs doing over and over again? So for example, where (what path) is /usr/bin/evince-thumbnailer trying to write to ".mate_desktop_thumbnail.6IWV5W" such that it's getting a violation? From the report, given: > Source Context unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 > Target Context unconfined_u:object_r:user_home_t:s0 Does that mean that the dir that evince-thumbnailer wants to use needs to be of context thumb_t and the dir it was trying to use was user_home_t? If the target dir was user_home_t, that probably means that evince-thumbnailer was trying to write to my TMPDIR which is ~/tmp. So how do we know which dir it was actually trying to write into? That would be most helpful in these reports yes?
How I wrote if it does not help and labeling is OK, please reopen the bug to discuss.
So are you able to locate the file? ~/tmp how you wrote above.
(In reply to Miroslav Grepl from comment #3) > How I wrote if it does not help and labeling is OK, please reopen the bug to > discuss. But my point previously is that I have been asked to do this "restorecon -R -v ~" many times in the past for previous/other selinux alerts. Surely this is something that should only ever need doing once, yes? Or is it expected that one has to relabel file systems "every now and then"? Like one has to reboot Windows machines "every now and then"? Surely if this relabeling needs doing repeatedly then something else is wrong that is getting the filesystem out of sync, yes? I'm just saying let's take a more analytical approach to this problem rather than mashing it once again with a big hammer. (In reply to Miroslav Grepl from comment #4) > So are you able to locate the file? > > ~/tmp > > how you wrote above. ~/tmp is not a file but a directory and yes, I can locate it (of course), it's at /home/brian/tmp because my ~ is /home/brian. $ ls -ldZ ~/tmp drwx-----x. brian brian system_u:object_r:user_tmp_t:s0 /home/brian/tmp But you didn't answer any of the questions I asked previously (in an effort to apply a little bit of analytics to this problem rather than mashing it with a hammer -- again. Specifically I asked: (In reply to Brian J. Murrell from comment #2) > > So for example, where (what path) is /usr/bin/evince-thumbnailer trying to > write to ".mate_desktop_thumbnail.6IWV5W" such that it's getting a violation? > > From the report, given: > > > Source Context unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 > > Target Context unconfined_u:object_r:user_home_t:s0 > > Does that mean that the dir that evince-thumbnailer wants to use needs to be > of context thumb_t and the dir it was trying to use was user_home_t? If the > target dir was user_home_t, that probably means that evince-thumbnailer was > trying to write to my TMPDIR which is ~/tmp. > > So how do we know which dir it was actually trying to write into?
(In reply to Brian J. Murrell from comment #5) > (In reply to Miroslav Grepl from comment #3) > > How I wrote if it does not help and labeling is OK, please reopen the bug to > > discuss. > > But my point previously is that I have been asked to do this "restorecon -R > -v ~" many times in the past for previous/other selinux alerts. Surely this > is something that should only ever need doing once, yes? Or is it expected > that one has to relabel file systems "every now and then"? Like one has to > reboot Windows machines "every now and then"? I am not able to remember who reports bugs to me in most cases :(. If we go thru bugs, sometimes there are some indications to help a user quickly. Basically issues like this are usually caused by upgrade issues, by permissive mode .... > > Surely if this relabeling needs doing repeatedly then something else is > wrong that is getting the filesystem out of sync, yes? I'm just saying > let's take a more analytical approach to this problem rather than mashing it > once again with a big hammer. Definitely we do it. We are doing it now. > > (In reply to Miroslav Grepl from comment #4) > > So are you able to locate the file? > > > > ~/tmp > > > > how you wrote above. > > ~/tmp is not a file but a directory and yes, I can locate it (of course), > it's at /home/brian/tmp because my ~ is /home/brian. > > $ ls -ldZ ~/tmp > drwx-----x. brian brian system_u:object_r:user_tmp_t:s0 /home/brian/tmp > > But you didn't answer any of the questions I asked previously (in an effort > to apply a little bit of analytics to this problem rather than mashing it > with a hammer -- again. > > Specifically I asked: > > (In reply to Brian J. Murrell from comment #2) > > > > So for example, where (what path) is /usr/bin/evince-thumbnailer trying to > > write to ".mate_desktop_thumbnail.6IWV5W" such that it's getting a violation? > > > > From the report, given: > > > > > Source Context unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 > > > Target Context unconfined_u:object_r:user_home_t:s0 > > > > Does that mean that the dir that evince-thumbnailer wants to use needs to be > > of context thumb_t and the dir it was trying to use was user_home_t? If the > > target dir was user_home_t, that probably means that evince-thumbnailer was > > trying to write to my TMPDIR which is ~/tmp. > > > > So how do we know which dir it was actually trying to write into?
And also restorecon -R -v ~/ would show us mislabeling issue. -v ... verbose
The question is where is it trying to write the .mate_desktop_thumbnail.6IWV5W file Does Mate have a special directory in the homedir where these files get written? One thing we could do is turn up the auditing to get us to the path. auditctl -w /etc/shadow THen get the AVC to happen again, this would generate a full path.
(In reply to Daniel Walsh from comment #8) > The question is where is it trying to write the > .mate_desktop_thumbnail.6IWV5W file I dunno. I guess that was the point I was trying to make back here: (In reply to Brian J. Murrell from comment #2) > > So for example, where (what path) is /usr/bin/evince-thumbnailer trying to > write to ".mate_desktop_thumbnail.6IWV5W" such that it's getting a violation? ... > So how do we know which dir it was actually trying to write into? That > would be most helpful in these reports yes? We shouldn't need to know the innards of the applications making the violations in order to determine how to rectify the contexts/rules to accommodate them. > Does Mate have a special directory in the homedir where these files get > written? Again, I don't know. > One thing we could do is turn up the auditing to get us to the path. It seems that having the path at the normal level would be most useful though, wouldn't it? > auditctl -w /etc/shadow Why /etc/shadow?
The watch is something that usually won't trigger, so it won't flood the logs. But when there is an audit rule loaded, the audit system collects more information so that its easier to debug AVC's.
Also let ask MATE folks.
I do not have a file called .mate_desktop_thumbnail* in my home folder in a Mate installation f20. Evince (works well here) and gnome is also installed, but selinux is complete disable here. Those are Mate's thumbnail folder. ~.cache/thumbnails/fail/mate-thumbnail-factory ~.cache/thumbnails/large ~.cache/thumbnails/normal @ Dear supporter Why not using Mate's mate-document-viewer, which is (-qt) equal to evince? If you need more info's about mate desktop. let me know.
no action anymore...re-asigned it back to the culprit.
atril-1.8.0-6.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/atril-1.8.0-6.fc20
Package atril-1.8.0-6.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing atril-1.8.0-6.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-9510/atril-1.8.0-6.fc20 then log in and leave karma (feedback).
atril-1.8.0-6.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.