On Mon, 2010-07-26 at 13:13 -0500, Xavier Toth wrote: > On Mon, Jul 26, 2010 at 8:44 AM, Xavier Toth <txtoth@xxxxxxxxx> wrote: > > On Sun, Jul 25, 2010 at 10:37 PM, merlin <merlin@xxxxxxxxxxxxxxxxxxx> wrote: > >>> Fuse can deal with xattrs but only AFTER the fuse userspace program > >>> believes the filesystem is mounted (and if the filesystem can handle > >>> it). My original patches didn't work, because I was calling getxattr > >>> during the mount(2) syscall. It gets even worse. We had a 'bug' in > >>> which the mount(8) program would call stat (or something like that) on > >>> the root inode before it told the fuse userspace program the mount was > >>> finished. The audit system checked for file capabilities on the stat > >>> call, which resulted in an xattr upcall, which resulted in a deadlock > >>> because the fuse userspace wouldn't answer until the mount finished. > >>> The 'fix' was to stop mount(8) from calling stat on fuse mounts. > >>> > >>> The 'right' solution (I think) is going to be 2 parts. First we need > >>> to get more information in the superblock mounting. I seem to recall > >>> that the only information we had was that it was 'fuse.' > > After looking at this for awhile it seems to me that fuse_get_sb needs > to call security_sb_set_mnt_opts get its superblock security structure > initialized especially for the case when I used the fs_use_xattrs in > policy. For most FS (everything but NFS referrals and submounts as I recall) this is supposed to get called via the vfs_kern_mount -> security_sb_kern_mount -> selinux_sb_kern_mount -> superblock_doinit -> selinux_set_mnt_opts call chain. If fuse isn't calling security_sb_kern_mount I'd have to think something is wrong... -Eric -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
