Re: graft_tree/attach_mnt rfc

From: Mike Wray (mike_wrayat_private)
Date: Fri Oct 04 2002 - 02:13:11 PDT

  • Next message: Mike Wray: "Re: [RFC] No more module_* hooks"

    ----- Original Message -----
    From: "Chris Wright" <chrisat_private>
    To: "Mike Wray" <mike_wrayat_private>
    Cc: "Serge E. Hallyn" <hallynat_private>; <linux-security-moduleat_private>
    Sent: Tuesday, October 01, 2002 8:38 PM
    Subject: Re: graft_tree/attach_mnt rfc
    
    
    > * Mike Wray (mike_wrayat_private) wrote:
    > >
    > > It looks like you are proposing that it should no longer be possible
    > > to veto a loopback mount with an LSM security hook, and that
    > > only controls for do_kern_mount() should remain.
    > > Like I said, we need to record all namespace operations,
    > > but we need to be able to veto a loopback mount too (mediate),
    > > so I'd be against that.
    >
    > Well, first, which loopback mount to you mean?  mount -o loop, or
    > mount --bind?  Assuming you mean do_loopback (--bind) how do you need to
    > control these operations?  Case by case, or simply disabling?
    > do_loopback() whether recursive or not eventually calls graft_tree which
    > would do the check on the new tree attachment.
    >
    
    OK, sloppy terminology. I was really thinking about mount --bind.
    However the point remains that in our model we track how the namespace maps
    to inodes. So we need to know when a mount has happened so we can update
    mappings. This means knowing about do_kern_mount() is not enough.
    We also control mounts when they cover up a directory with files in it - because
    that effectively replaces the files. So we need to be able to veto mounts.
    
    > > BTW, in Serge and Chris's patches moving the sb_post_addmount hook
    > > from the end of graft_tree() into attach_mount() means that it
    > > would be called with the dcache_lock held - whereas before
    > > it wasn't.
    >
    > Yes, this is a known side effect.
    >
    
    This is a problem for us because our present code for handling a mount involves
    looking up filenames, which will be bad if the dcache_lock is held...
    
    > > It also means that sb_post_addmount() might be called
    > > multiple times on one mount (via copy_tree()).
    >
    > This is rather intentional so that recursive bind mounts and
    > copy_namespace operations get the full picture.
    
    OK, but it means that we don't have a clear idea when a mount is finished -
    because we can't tell which of the sb_post_addmount() calls is the last.
    We'd like a hook that is called when the mount is done - so we can do all our
    work once.
    
    Mike
    
    
    _______________________________________________
    linux-security-module mailing list
    linux-security-moduleat_private
    http://mail.wirex.com/mailman/listinfo/linux-security-module
    



    This archive was generated by hypermail 2b30 : Fri Oct 04 2002 - 02:14:31 PDT