Re: [RFC] Add a counter in task_struct for skipping permission check. (Was: Should LSM hooks be called by filesystem's requests?)

From: Erez Zadok
Date: Tue Jul 22 2008 - 13:31:24 EST

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at