In message <200807221959.HDJ90154.FFLMOtVOOQJFSH@xxxxxxxxxxxxxxxxxxx>, Tetsuo Handa writes: > Hello. > > I have a problem with unionfs and LSM. > The unionfs causes NULL pointer dereference if copyup_dentry() > failed by LSM's decision, so I'm searching for a solution. > > http://marc.info/?l=linux-security-module&m=121609490418118&w=2 > > It seems that the unionfs is not handling error paths correctly. > But since the unionfs's operation is not always atomic, > there is no guarantee that unionfs can rollback unionfs's internal > operations properly. > > For example, unionfs is trying to create a rw copy of a ro file. > > Request by unionfs Decision by LSM > "I want to create a rw file." "OK. You can create the file." > "I want to copy the ro file's attribute" "No. You must not." > "I have to delete the rw file." "No. You must not." > > Then, it might be better to completely disable LSM for unionfs's > internal operations. > At least, I think we need to disable LSM for rollback operation so that > the rw file in the above example is properly deleted. > > I think this patch can disable LSM checks if vfs_*() and > notify_change() is called by unionfs's internal operations. > This patch is just an idea, not tested at all. > > Does somebody have a solution? I think there needs to be a better way for stackable f/s to work with LSM/Smack, and the VFS. I'd like to do things as cleanly as possible, not just come up with quick-n-dirty hacks or workarounds. :-) One possibility I'm looking into is the S_PRIVATE flag. Another is cap_raise/lower pairs. Ideally there'd be a way to pass security-related flags to vfs_* methods, but I think that generally such solutions haven't been received well. (If the LSM folks know of a better/cleaner way in which Unionfs can utilize LSM, I'd love to hear about it.) In the end, I believe the solution would be some combination of improved VFS and changes to Unionfs. The atomicity issue is a problem for all stackable file systems, yes. Viro had suggested to me at LSF'08 that perhaps the superblock struct would need a "want_write" type of interface as has been done struct vfsmount: that'd allow an upper layer to make multiple ops on a lower superblock, locking it from any possible interleaving of other callers, and even rolling back undesired changes. Cheers, Erez. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
