A couple of points: - Don't conflate use of fuse with sdcard daemon (mainline Android) with use of sdcardfs (seems to be a kernel-resident filesystem based on wrapfs from the stackable filesystems work, appearing at least in some Samsung devices, see fs/sdcardfs in Samsung kernel trees).
- For fuse and the sdcard daemon, yes, we can either use getpidcon() in the sdcard daemon and leave fuse unchanged or extend the fuse kernel api to pass up the process context directly or offer it up via another call. That's for identifying the subject. - For fuse and xattr support, there is a longstanding problem with a deadlock between at least some fuse filesystems and SELinux when using fs_use_xattr. The issue is that SELinux requests the security.selinux xattr for the root directory inode during mount(), and common FUSE filesystems will deadlock if they get a request on a file within the filesystem during the mount operation. See fuse discussions on selinux list. Don't know for sure if that's an issue with the sdcard daemon. If not or if that can be easily resolved (permit incoming requests on other threads while the mount is still being processed), then the next obvious question is how does the sdcard daemon obtain or synthesize the attribute values, particularly when the underlying storage is a real SDcard with a vfat filesystem. On Fri, Jan 2, 2015 at 1:39 PM, William Roberts <[email protected]> wrote: > So I was looking at the todo's placed on the bitbucket site. I figured I > would take on the FUSE stuff, since that interests me the most. > > Outside of my first tought of grabbing PID from fuse_in_header and doing a > lookup which is mentioned in the wiki blurb on fuse. > > Stephen thinks the problem here is that pid can torially wrap, causing the > fs to lookup the context of the wrong application. While possible, the worst > case scenario is that data gets released t the FUSE driver, but since the > original application requesting the data is dead for this occur, I dont > think it matters. > > My second thought is, cant we just implement xattr support in the sdcard > userspace portion of the fuse filesystem and selinux.security getxattr > calls? > > I was looking at the kernel code in selinux and looks like it just calls the > indode operation for getxattr, which should result with fuse forwarding it > to the userspace fs. > > Then can't we just configure SELinux to use xattrs on fuse via: > fs_use_xattr fuse u:object_r:labeledfs:s0; > > And lastly add the support to sdcardfs. > > If these ideas doen't work out of the box (except the userspace portion), > the other options get gross quick considering that the security field in the > cred struct is an apaque pointer. We could replace the padding portion of > fuse_in_header which is a uint32_t with a 4 byte identifier and some common > method for lsms to populate it. This, a call to some generic method would > call an lsm specific handler to populate this field, for SELinux, it could > be the SID, but this seems awful. > > > -- > Respectfully, > > William C Roberts > > > _______________________________________________ > Seandroid-list mailing list > [email protected] > To unsubscribe, send email to [email protected]. > To get help, send an email containing "help" to > [email protected]. _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
