This patch allows VFS wrapper functions associate "struct vfsmount"
with "struct task_struct" so that LSM hooks can calculate
pathname of given "struct dentry".
Signed-off-by: Tetsuo Handa <[email protected]>
---
include/linux/init_task.h | 1 +
include/linux/sched.h | 2 ++
2 files changed, 3 insertions(+)
--- linux-2.6-mm.orig/include/linux/init_task.h
+++ linux-2.6-mm/include/linux/init_task.h
@@ -187,6 +187,7 @@ extern struct group_info init_groups;
.dirties = INIT_PROP_LOCAL_SINGLE(dirties), \
INIT_TRACE_IRQFLAGS \
INIT_LOCKDEP \
+ .last_vfsmount = NULL, \
}
--- linux-2.6-mm.orig/include/linux/sched.h
+++ linux-2.6-mm/include/linux/sched.h
@@ -1238,6 +1238,8 @@ struct task_struct {
int make_it_fail;
#endif
struct prop_local_single dirties;
+ /* vfsmount info for LSM hooks. */
+ struct vfsmount *last_vfsmount;
};
/*
--
I must say I personally prefer the apparmor approach. But I'd recommend
you get together and get this piece pushed on its own, whichever version
you can agree on. Yes it needs a user, but at this point I would think
both tomoyo and apparmor have had enough visibility that everyone knows
the intended users.
It seems to me you're both being held up by this piece, and getting
another full posting of either tomoyo or apparmor isn't going to help,
so hopefully you can combine your efforts to get this solved.
thanks,
-serge
Quoting Kentaro Takeda ([email protected]):
> This patch allows VFS wrapper functions associate "struct vfsmount"
> with "struct task_struct" so that LSM hooks can calculate
> pathname of given "struct dentry".
>
> Signed-off-by: Tetsuo Handa <[email protected]>
> ---
> include/linux/init_task.h | 1 +
> include/linux/sched.h | 2 ++
> 2 files changed, 3 insertions(+)
>
> --- linux-2.6-mm.orig/include/linux/init_task.h
> +++ linux-2.6-mm/include/linux/init_task.h
> @@ -187,6 +187,7 @@ extern struct group_info init_groups;
> .dirties = INIT_PROP_LOCAL_SINGLE(dirties), \
> INIT_TRACE_IRQFLAGS \
> INIT_LOCKDEP \
> + .last_vfsmount = NULL, \
> }
>
>
> --- linux-2.6-mm.orig/include/linux/sched.h
> +++ linux-2.6-mm/include/linux/sched.h
> @@ -1238,6 +1238,8 @@ struct task_struct {
> int make_it_fail;
> #endif
> struct prop_local_single dirties;
> + /* vfsmount info for LSM hooks. */
> + struct vfsmount *last_vfsmount;
> };
>
> /*
>
> --
> -
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello.
Serge E. Hallyn wrote:
> I must say I personally prefer the apparmor approach.
No problem.
> But I'd recommend
> you get together and get this piece pushed on its own, whichever version
> you can agree on.
TOMOYO can use AppArmor's patch.
> Yes it needs a user, but at this point I would think
> both tomoyo and apparmor have had enough visibility that everyone knows
> the intended users.
Not only AppArmor and TOMOYO but also SELinux want to use "vfsmount".
(http://marc.info/?l=selinux&m=120005904211942&w=2)
> It seems to me you're both being held up by this piece, and getting
> another full posting of either tomoyo or apparmor isn't going to help,
> so hopefully you can combine your efforts to get this solved.
We welcome AppArmor's vfsmount patches, but I wonder why AppArmor's
vfsmount patches are not merged yet.
What prevents AppArmor's vfsmount patches from merging into -mm tree?
Regards.
Kentaro Takeda
Quoting Kentaro Takeda ([email protected]):
> Hello.
>
> Serge E. Hallyn wrote:
> > I must say I personally prefer the apparmor approach.
> No problem.
>
> > But I'd recommend
> > you get together and get this piece pushed on its own, whichever version
> > you can agree on.
> TOMOYO can use AppArmor's patch.
Right, but one will be preferred by the community - and while I have my
own preference, I wouldn't put too much faith on that, rather talk with
the apparmor folks, look over the lkml logs for previous submissions,
and then decide.
> > Yes it needs a user, but at this point I would think
> > both tomoyo and apparmor have had enough visibility that everyone knows
> > the intended users.
> Not only AppArmor and TOMOYO but also SELinux want to use "vfsmount".
> (http://marc.info/?l=selinux&m=120005904211942&w=2)
>
> > It seems to me you're both being held up by this piece, and getting
> > another full posting of either tomoyo or apparmor isn't going to help,
> > so hopefully you can combine your efforts to get this solved.
> We welcome AppArmor's vfsmount patches, but I wonder why AppArmor's
> vfsmount patches are not merged yet.
>
> What prevents AppArmor's vfsmount patches from merging into -mm tree?
I don't recall what objections remained at the last posting. Far as I
know there may have simply been no responses due to patch fatigue. (it
happens)
-serge
Serge:
> Right, but one will be preferred by the community - and while I have my
> own preference, I wouldn't put too much faith on that, rather talk with
> the apparmor folks, look over the lkml logs for previous submissions,
> and then decide.
Thanks for your advice.
We got the same advice from Jonathan@LWN in Embedded Linux Conference 2007,
and contacted AppArmor folks but no action occurred. We'll try to contact again.
John Johansen:
Both AppArmor and TOMOYO need vfsmount in LSM hooks. Although we suggested
another solution in [TOMOYO #6], we can use AppArmor's approach.
How about submitting only vfsmount patches before submitting AppArmor/TOMOYO
main module?
We think the patches relate to not only LSM folks but also fsdevel folks.
So we are going to post the brief description of the patches to fsdevel.
Regards,
Kentaro Takeda