Re: fuse and selinux don't seem to work well together

[Eric Paris <eparis@redhat.com>]

On Mon, 2010-07-26 at 16:31 -0400, David P. Quigley wrote:
> On Mon, 2010-07-26 at 15:22 -0500, Xavier Toth wrote:
> > On Mon, Jul 26, 2010 at 2:22 PM, David P. Quigley <dpquigl@tycho.nsa.gov> wrote:
> > > Ok so looking through the code briefly this is what happens with respect
> > > to the fstype for fuse. In the user space mount programs for fuse it
> > > handles all of the parsing of the source string to grab the fuse fs type
> > > out of it. It then crafts an FS type fuse.<subname> which is sent to the
> > > kernel. The creation of the daemon to handle the requests is done in
> > > user space and then it calls open on /dev/fuse. This grabs a new file
> > > descriptor which the kernel uses as its communications channel to the
> > > user space library and this FD is passed with the mount command.
> > >
> > > Now here is where my understanding gets a little foggy but hopefully it
> > > will help. Looking at the file_system_type structure for the fuse fs
> > > type it has a flag called FS_HAS_SUBTYPE. Looking closely do_kern_mount
> > > does two things to the fs_type string. First it will call get_fs_type
> > > which pulls off the subtype leaving the base type. This is passed into
> > > vfs_kernel_mount to be processed. After it calls vfs_kern_mount it then
> > > checks if fs_flags has FS_HAS_SUBTYPE set and if it does calls
> > > fs_set_subtype. This strips the first part of the name off and sets the
> > > s_subtype field in the superblock. When the name finally arrives at
> > > selinux_set_mnt_opts the file system name is fuse. This gets passed into
> > > security_fs_use at some point to determine the labeling type for the
> > > file system and grabs the entry in the policy db for fuse and uses that.
> > > So having the fuse code call security_set_mnt_opts earlier isn't a good
> > > idea.
> > >
> > > Now if you want to attempt to use the subtype in a fsuse statement we
> > > need to set the subtype before calling vfs_kern_mount. I'm not sure if
> > > this is allowed so something else might have to be done instead. I hope
> > > this clears some things up for you.
> > >
> > > Dave
> > >
> > >
> > 
> > If I understand you're saying that the superblock file_system_type
> > name needs to be type.subtype when it get to selinux_set_mnt_opts for
> > security_fs_use to find the policy I've configured?
> > 
> > Ted
> 
> That would be true if you wanted to write rules like
> fs_use_xattr(fuse.sshfs....) Steve seems to think a better plan is to
> take Eric's patch and see if we can resolve the deadlock issues. This
> way if you add a file system in the future that uses xattrs you don't
> have to add a new entry to the policy.

I'm not sure how the deadlock issues can be 'solved.'  The fuse people
have repeatedly stated that until mount(8) (not even mount (2)) is
finished it is illegal to call call getxattr() and they have every right
to deadlock.  They will not budge on this position.

The only possibility I can think of is to extend fuse such that the
support of xattrs is known during mount(2).   No idea what that would
look like.

I believe that my autodetection patch is dead in the water with fuse as
it stands today....

-Eric


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.