[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200912250655.HEC04690.FFVJQSOLHOtMFO@I-love.SAKURA.ne.jp>
Date: Fri, 25 Dec 2009 06:55:08 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: ebiederm@...ssion.com
Cc: michael@...top.org, linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org, andi@...stfloor.org,
david@...g.hm, socketcan@...tkopp.net, alan@...rguk.ukuu.org.uk,
herbert@...dor.apana.org.au, Valdis.Kletnieks@...edu,
bdonlan@...il.com, zbr@...emap.net, cscott@...ott.net,
jmorris@...ei.org, bernie@...ewiz.org, mrs@...hic-beasts.com,
randy.dunlap@...cle.com, xiyou.wangcong@...il.com
Subject: Re: A basic question about the security_* hooks
Eric W. Biederman wrote:
> My immediate impression is that the big limitation today is the
> sharing of the void * security data members of strucutres.
I think the time to change "void * security" is approaching.
What about allocating dedicated "void *" for each in-tree security modules and
let proposed security modules use "void * security" so that proposed security
modules can be evaluated without allocating dedicated "void *", something like
struct foo {
...
#ifdef CONFIG_SECURITY_SELINUX
void *selinux;
#endif
#ifdef CONFIG_SECURITY_SMACK
void *smack;
#endif
#ifdef CONFIG_SECURITY_PROPOSED
void *security
#endif
}
struct bar {
...
#ifdef CONFIG_SECURITY_SELINUX
void *selinux;
#endif
#ifdef CONFIG_SECURITY_PROPOSED
void *security
#endif
}
?
Regarding TOMOYO, "void * security" automatically added to many structure is
nothing but waste of memory because TOMOYO don't need "void * security" except
"struct task_struct".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists