Description of problem:
When running with selinux-policy-mls in enforcing if a directory contains files labeled at different levels/mls ranges for instance s1, s2 then nautilus may not show any files when you navigate to that directory. ls will show file names of files but no other info which is the model that should be followed by nautilus.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. configure /etc/selinux/config SELINUXTYPE=mls, SELINUX=enforcing
2. boot with enforcing=0 for setup of test
3. Create a user and use semanage to set the users login to SELinux User staff_u and MLS Range to SystemLow-SystemHigh
4. login as newly created user
5. mkdir test
6. newrole -l Secret-Secret
7. touch test/secret
9. newrole -l Unclassified-Unclassified
10. touch test/unclass
12. reboot to enforcing mode
13. login as user
13. bring up file browser and navigate to test directory
You won't see files secret or unclass.
Should see file names but no other stat info should appear.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release. Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release. This request is not yet committed for
Created attachment 410000 [details]
Even though stat returned an error go ahead and return the info object along with the error becaause it contains the file name which maybe of value to the calling process i.e. nautilus.
Changing component to glib2 as this is GIO issue.
(In reply to comment #3)
> Created an attachment (id=410000) [details]
> possible patch
> Even though stat returned an error go ahead and return the info object along
> with the error becaause it contains the file name which maybe of value to the
> calling process i.e. nautilus.
Ted, I appreciate your initiative, but the patch is not completely right. (besides you're leaking some objects as the result and error cannot be set/present at the time).
I still need to look at this on a running system with MLS but if I understand it correctly, we can read the directory but can't stat the files themselves. The GIO API is designed to collect several attributes at a time, not setting those who are unreadable. Usually not being able to stat the file means it's unusable for further use in the applications but I guess it should still be included in the enumeration.
I'll look at this more soon, for the start you can try fiddling with gvfs- commands to see if it's really a GIO fault or nautilus one. How does GtkFileChooser behave in this setup btw.?
I must admit I'm not vary familiar with glib. What's leaking? Where does it say that the result and error cannot be set/present at the same time?
I'll try a GtkFileChooser.
[tedx@localhost ~]$ gvfs-ls test
Error: Error stating file '/home/tedx/test/confidential': Permission denied
[tedx@localhost ~]$ ls test
ls: cannot access test/secret: Permission denied
ls: cannot access test/confidential: Permission denied
ls: cannot access test/unclassified: Permission denied
confidential secret unclassified
File chooser test code:
fc = gtk.FileChooserDialog(title='Open File...',
response = fc.run()
No files appear.
Tomas where do we stand on this bug?
Created attachment 427967 [details]
Proposed patch, modifying local GIO behaviour a little. When we get the EACCESS error on stat(), we still try to collect other attributes. No error is propagated to clients and only some attributes are set (usually name, display-name, edit-name, copy-name). Any other cases, error is fatal just like before. Please correct me if we can get any other types of errors with MLS.
From my testing it doesn't seem to break any stuff on restricted files, applications will still report error during reading the contents. And we can't sniff/guess MIME type, can't distinguish between regular file and directory, can't even get selinux context or any xattrs.
Looks reasonable however the first chunk is unnecessary. I'll test it too.
Created attachment 428430 [details]
Updated patch, which allows partial MIME type guessing. This is done by sniffing the content with simple guess by filename extension when it fails. Still, it won't detect whether the file is a regular file or directory so we might end up with image/jpeg type for an unreadable folder. But that's the design limitation.
Patch looks good to me.
Upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=623692
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.