Bug 586412 - directory with file at multiple MLS levels may not display any files
Summary: directory with file at multiple MLS levels may not display any files
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: glib2
Version: 6.0
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Tomáš Bžatek
QA Contact: desktop-bugs@redhat.com
Depends On:
TreeView+ depends on / blocked
Reported: 2010-04-27 13:58 UTC by Ted X Toth
Modified: 2015-03-03 22:47 UTC (History)
10 users (show)

Fixed In Version: glib2-2.22.5-4.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-11-10 20:28:45 UTC
Target Upstream Version:

Attachments (Terms of Use)
possible patch (573 bytes, patch)
2010-04-29 01:35 UTC, Ted X Toth
no flags Details | Diff
glib-2.22.5-gio-local-stat-selinux-mls.patch (5.85 KB, patch)
2010-06-30 12:09 UTC, Tomáš Bžatek
no flags Details | Diff
glib-2.22.5-gio-local-stat-selinux-mls-2.patch (6.26 KB, patch)
2010-07-01 13:58 UTC, Tomáš Bžatek
no flags Details | Diff

Description Ted X Toth 2010-04-27 13:58:28 UTC
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):

How reproducible:

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
8. exit
9. newrole -l Unclassified-Unclassified
10. touch test/unclass
11. exit
12. reboot to enforcing mode
13. login as user
13. bring up file browser and navigate to test directory

Actual results:
You won't see files secret or unclass.

Expected results:
Should see file names but no other stat info should appear.

Additional info:

Comment 2 RHEL Program Management 2010-04-27 15:57:38 UTC
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

Comment 3 Ted X Toth 2010-04-29 01:35:35 UTC
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.

Comment 4 Tomáš Bžatek 2010-05-03 16:02:59 UTC
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.?

Comment 5 Ted X Toth 2010-05-03 20:49:35 UTC
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.

Comment 6 Ted X Toth 2010-05-03 23:26:43 UTC
[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...',
response = fc.run()


No files appear.

Comment 7 Daniel Walsh 2010-06-17 12:32:59 UTC
Tomas where do we stand on this bug?

Comment 9 Tomáš Bžatek 2010-06-30 12:09:23 UTC
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.

Comment 10 Ted X Toth 2010-06-30 13:22:58 UTC
Looks reasonable however the first chunk is unnecessary. I'll test it too.

Comment 11 Tomáš Bžatek 2010-07-01 13:58:08 UTC
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.

Comment 12 Matthias Clasen 2010-07-06 14:59:26 UTC
Patch looks good to me.

Comment 13 Matthias Clasen 2010-07-06 15:38:15 UTC
Upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=623692

Comment 16 releng-rhel@redhat.com 2010-11-10 20:28:45 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.