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

[Eric Paris <eparis@redhat.com>]

On Mon, 2010-07-26 at 17:40 -0400, David P. Quigley wrote:
> <snip>
> > 
> > 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
> 
> So where is this dead locking occuring? The only thing kernel side that
> I can think might deadlock is mount will probably lock the new super
> block for writing (although it shouldn't be available yet so maybe not)
> and when we call vfs_getxattr on the mount point it might need to grab a
> lock on the sb for something. I don't think this is the case since I
> looked through the code from vfs_getxattr through the fuse getxattr
> handler and I don't see any locking in there for the SB. I'm more
> inclined to believe that it is the userspace code for fuse or the
> interface they use to send the requests to user space. Actually the
> latter sounds more reasonable since fuse_send_request places the request
> in a queue. So if we are waiting on mount to finish before we send the
> getxattr request but mount depends on the getxattr request we can have a
> problem. Maybe the mount request can be modified to make a nested
> getxattr call on the file system to find out of it is supported and if
> it is add something to indicate xattr support?

It's not an in kernel deadlock.  fuse userspace refuses to respond to
anything until mount(8) is finished.  So if mount(8) at any point (even
during mount(2)) is waiting on the fuse userspace to respond you are
just stuck.

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