* Re: Module stacking next steps [not found] <5536F260.3080201@schaufler-ca.com> @ 2015-04-30 1:55 ` James Morris 2015-04-30 2:02 ` Kees Cook 2015-04-30 2:45 ` John Johansen 0 siblings, 2 replies; 6+ messages in thread From: James Morris @ 2015-04-30 1:55 UTC (permalink / raw) To: Casey Schaufler, Stephen Smalley, John Johansen, Kees Cook, Paul Moore Cc: LSM, James Morris, linux-kernel On Tue, 21 Apr 2015, Casey Schaufler wrote: > > James, do you want to take the module stacking changes in through > the security tree? Are there remaining objections or concerns? What > procedure would you like to follow? What's the overall consensus on this -- do people generally see it as useful and necessary, and is it ready to go in? Any objections or concerns? -- James Morris <jmorris@namei.org> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Module stacking next steps 2015-04-30 1:55 ` Module stacking next steps James Morris @ 2015-04-30 2:02 ` Kees Cook 2015-04-30 2:45 ` John Johansen 1 sibling, 0 replies; 6+ messages in thread From: Kees Cook @ 2015-04-30 2:02 UTC (permalink / raw) To: James Morris Cc: Casey Schaufler, Stephen Smalley, John Johansen, Paul Moore, LSM, James Morris, linux-kernel On Thu, Apr 30, 2015 at 11:55:51AM +1000, James Morris wrote: > On Tue, 21 Apr 2015, Casey Schaufler wrote: > > > > > James, do you want to take the module stacking changes in through > > the security tree? Are there remaining objections or concerns? What > > procedure would you like to follow? > > What's the overall consensus on this -- do people generally see it as > useful and necessary, and is it ready to go in? At the very worst, I see it as a very nice clean up. At best, I see it as extremely useful for the things I want to do, with various "minor" LSM working together. > Any objections or concerns? As far as I'm concerned, I'm very happy with it. Thanks! -Kees -- Kees Cook @outflux.net ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Module stacking next steps 2015-04-30 1:55 ` Module stacking next steps James Morris 2015-04-30 2:02 ` Kees Cook @ 2015-04-30 2:45 ` John Johansen 2015-04-30 11:20 ` James Morris 1 sibling, 1 reply; 6+ messages in thread From: John Johansen @ 2015-04-30 2:45 UTC (permalink / raw) To: James Morris, Casey Schaufler, Stephen Smalley, Kees Cook, Paul Moore Cc: LSM, James Morris, linux-kernel On 04/29/2015 06:55 PM, James Morris wrote: > On Tue, 21 Apr 2015, Casey Schaufler wrote: > >> >> James, do you want to take the module stacking changes in through >> the security tree? Are there remaining objections or concerns? What >> procedure would you like to follow? > > What's the overall consensus on this -- do people generally see it as > useful and necessary, and is it ready to go in? > > Any objections or concerns? > No objections, and I know there are several people interested in seeing this land. I am happy with the code, and my only concerns lie with things that this explicitly doesn't support yet (ie. larger lsm stacking, secids, ...) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Module stacking next steps 2015-04-30 2:45 ` John Johansen @ 2015-04-30 11:20 ` James Morris 2015-04-30 14:48 ` Casey Schaufler 0 siblings, 1 reply; 6+ messages in thread From: James Morris @ 2015-04-30 11:20 UTC (permalink / raw) To: John Johansen Cc: Casey Schaufler, Stephen Smalley, Kees Cook, Paul Moore, LSM, James Morris, linux-kernel On Wed, 29 Apr 2015, John Johansen wrote: > On 04/29/2015 06:55 PM, James Morris wrote: > > On Tue, 21 Apr 2015, Casey Schaufler wrote: > > > >> > >> James, do you want to take the module stacking changes in through > >> the security tree? Are there remaining objections or concerns? What > >> procedure would you like to follow? > > > > What's the overall consensus on this -- do people generally see it as > > useful and necessary, and is it ready to go in? > > > > Any objections or concerns? > > > No objections, and I know there are several people interested in seeing > this land. > > I am happy with the code, and my only concerns lie with things that this > explicitly doesn't support yet (ie. larger lsm stacking, secids, ...) Ok, Casey, please send an updated final version for everyone to check. -- James Morris <jmorris@namei.org> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Module stacking next steps 2015-04-30 11:20 ` James Morris @ 2015-04-30 14:48 ` Casey Schaufler 2015-04-30 15:10 ` Casey Schaufler 0 siblings, 1 reply; 6+ messages in thread From: Casey Schaufler @ 2015-04-30 14:48 UTC (permalink / raw) To: James Morris, John Johansen Cc: Stephen Smalley, Kees Cook, Paul Moore, LSM, James Morris, linux-kernel, Casey Schaufler On 4/30/2015 4:20 AM, James Morris wrote: > On Wed, 29 Apr 2015, John Johansen wrote: > >> On 04/29/2015 06:55 PM, James Morris wrote: >>> On Tue, 21 Apr 2015, Casey Schaufler wrote: >>> >>>> James, do you want to take the module stacking changes in through >>>> the security tree? Are there remaining objections or concerns? What >>>> procedure would you like to follow? >>> What's the overall consensus on this -- do people generally see it as >>> useful and necessary, and is it ready to go in? >>> >>> Any objections or concerns? >>> >> No objections, and I know there are several people interested in seeing >> this land. >> >> I am happy with the code, and my only concerns lie with things that this >> explicitly doesn't support yet (ie. larger lsm stacking, secids, ...) > Ok, Casey, please send an updated final version for everyone to check. Are you planning to update security-next soon? I think that it will be easier for everyone if I base it on the 4.1-rc than the 4.0-rc. Alternatively, I could base it on 4.0. I can do any of 'em, but I'd hate to have to do it more often than I have to. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Module stacking next steps 2015-04-30 14:48 ` Casey Schaufler @ 2015-04-30 15:10 ` Casey Schaufler 0 siblings, 0 replies; 6+ messages in thread From: Casey Schaufler @ 2015-04-30 15:10 UTC (permalink / raw) To: James Morris, John Johansen Cc: Stephen Smalley, Kees Cook, Paul Moore, LSM, James Morris, linux-kernel, Casey Schaufler On 4/30/2015 7:48 AM, Casey Schaufler wrote: > On 4/30/2015 4:20 AM, James Morris wrote: >> On Wed, 29 Apr 2015, John Johansen wrote: >> >>> On 04/29/2015 06:55 PM, James Morris wrote: >>>> On Tue, 21 Apr 2015, Casey Schaufler wrote: >>>> >>>>> James, do you want to take the module stacking changes in through >>>>> the security tree? Are there remaining objections or concerns? What >>>>> procedure would you like to follow? >>>> What's the overall consensus on this -- do people generally see it as >>>> useful and necessary, and is it ready to go in? >>>> >>>> Any objections or concerns? >>>> >>> No objections, and I know there are several people interested in seeing >>> this land. >>> >>> I am happy with the code, and my only concerns lie with things that this >>> explicitly doesn't support yet (ie. larger lsm stacking, secids, ...) >> Ok, Casey, please send an updated final version for everyone to check. > Are you planning to update security-next soon? I think that it will > be easier for everyone if I base it on the 4.1-rc than the 4.0-rc. > Alternatively, I could base it on 4.0. I can do any of 'em, but I'd > hate to have to do it more often than I have to. Whoops! I read mail addressed directly to me before I read what goes just to lists. I see that security-next is updated. I will have the update ready as quickly as possible. Thank you. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-04-30 15:10 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <5536F260.3080201@schaufler-ca.com>
2015-04-30 1:55 ` Module stacking next steps James Morris
2015-04-30 2:02 ` Kees Cook
2015-04-30 2:45 ` John Johansen
2015-04-30 11:20 ` James Morris
2015-04-30 14:48 ` Casey Schaufler
2015-04-30 15:10 ` Casey Schaufler
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.