* 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. > 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. > 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. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net _______________________________________________ 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 : Tue Oct 01 2002 - 12:47:30 PDT