From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: fuse and selinux don't seem to work well together From: Eric Paris To: Xavier Toth Cc: Eric Paris , Stephen Smalley , "David P. Quigley" , SELinux In-Reply-To: References: <1279909967.8180.43.camel@moss-terrapins.epoch.ncsc.mil> <1279913697.32473.8.camel@moss-pluto.epoch.ncsc.mil> Content-Type: text/plain; charset="UTF-8" Date: Mon, 26 Jul 2010 17:35:48 -0400 Message-ID: <1280180148.23427.97.camel@localhost> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Mon, 2010-07-26 at 16:15 -0500, Xavier Toth 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. > > So is this past tense, there was a bug in mount(8) that has been addressed? That's correct. mount(8) now has a --no-canonicalize option which fuse uses to make it not call stat before it completes to avoid the deadlock. > > 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.' Not that is > > was fuse mounting ntfs. > > It appear that the superblock contains s_type->name and s_subtype > which should tell you that it is for example an fuse.ntfs mount. > > > After that we need to fix the other bug you > > pointed out (and other bug I half worked on and you might be able to > > find the patch in the archives somewhere) > > Sorry I'm not sure which bug you are referring to? > http://marc.info/?l=selinux&m=121379719014155&w=2 appears to be your > patch which I will look into applying. I was thinkin of these: http://www.nsa.gov/research/selinux/list-archive/0805/26041.shtml genfscon is not allowed in modules. I stop looking when I realized that those don't really handle the mls portion of the label correctly... So sds wants to autodetect xattr support. that sounds great, but I think is a large project that will require redesigning fuse. I am suggesting a smaller interim solution that consists of 2 steps. 1) get all the information about the name you need into the kernel in the right place. aka s_type->name and s_subtype in the right hook. I think David indicated that is going to take some kernel reworking to get s_subtype set at the appropriate time. 2) add support to the policy to support filesystem labeling rules in modules. I believe this is going to require the changes I was talking about in the above link. -- 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.