On 01/12/2012 02:40 PM, Steve Beattie wrote: > On Fri, Jan 06, 2012 at 09:53:17AM -0800, John Johansen wrote: >> Add the library interface and untility functions to provide access to >> profile stacking. This allows a task to have its confinement based off >> of multiple profiles. >>
<<snip>> > >> + >> +Open file descriptors may have to be revalidated after the stacking to >> +account for the new mediation controls on the task. >> + >> +The aa_stackcon_onexec() function is like the aa_stackcon() function except >> +it specifies that the the stacking transition should take place on the >> +next exec instead of immediately. The delayed stacking takes precedence >> +over any exec transition rules within the confining profile. > > A separate question from this patch, but how are threads affected by > this? For example, if one thread calls aa_stackcon() and another thread > calls exec(), will it have the aa_stackcon_onexec() applied to it? If a > process > calls aa_stackcon_onexec() and then makes a clone() call, what will the > behavior of subsequent exec()s be? > Interesting question. Currently it behaves like change_onexec, it sets the information in a task (thread in this case) specific field. If the thread does a clone, the clone inherits the field from the thread that called clone. If a thread calls exec the field of the thread calling exec is used. This could lead to unexpected behavior, the solution would be to block change_onexec and stack if there is more than one thread in the process. -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
