On Tue, Jan 04, 2022 at 12:03:58PM -0500, Stefan Berger wrote: > From: Stefan Berger <stefanb@xxxxxxxxxxxxx> > > To prepare for virtualization of SecurityFS, use simple_pin_fs and > simpe_release_fs only when init_user_ns is active. > > Extend 'securityfs' for support of IMA namespacing so that each > IMA (user) namespace can have its own front-end for showing the currently > active policy, the measurement list, number of violations and so on. > > Enable multiple instances of securityfs by keying each instance with a > pointer to the user namespace it belongs to. > > Drop the additional dentry reference to enable simple cleanup of dentries > upon umount. Now the dentries do not need to be explicitly freed anymore > but we can just rely on d_genocide() and the dcache shrinker to do all > the required work. Looks brittle... What are the new rules for securityfs_remove()? Is it still paired with securityfs_create_...()? When is removal done? On securityfs instance shutdown? What about the underlying data structures, BTW? When can they be freed? That kind of commit message is asking for trouble down the road; please, document the rules properly. Incidentally, what happens if you open a file, pass it to somebody in a different userns and try to shut the opener's userns down?
