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
inclusion.

Created attachment 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.

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
[tedx@localhost ~]$ 

File chooser test code:

import gtk

fc = gtk.FileChooserDialog(title='Open File...',
                                   parent=None,
                                   action=gtk.FILE_CHOOSER_ACTION_OPEN,
                                   buttons=(gtk.STOCK_CANCEL,gtk.RESPONSE_CANCEL,gtk.STOCK_OPEN,gtk.RESPONSE_OK))
fc.set_current_folder("/home/tedx/test")
fc.set_default_response(gtk.RESPONSE_OK)
response = fc.run()

fc.destroy()

No files appear.

Tomas where do we stand on this bug?

Created attachment 427967 [details]
glib-2.22.5-gio-local-stat-selinux-mls.patch

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]
glib-2.22.5-gio-local-stat-selinux-mls-2.patch

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.