[apparmor] [RFC PATCH 1/1] libapparmor: Create man page for aa_stack_profile()/aa_stack_onexec()

[Tyler Hicks]

On 2016-01-13 20:08:38, Seth Arnold wrote:
> On Tue, Jan 12, 2016 at 03:10:28PM -0800, John Johansen wrote:
> > now lets look at the stack on exec case. The stack addition is delayed
> > until exec.  The current profile will have the stack added on top, the
> > question is when and how.
> > 
> > 1. stack_onexec as stack + change_onexec: stack is computed immediately
> >     but the transition is delayed until exec (this overrides any
> >     transitions and is how Tyler described it)
> >   A -- stack_onexec B -- exec --> A//&B
> > 
> > 2. stack_onexec, stack delayed until exec applied pre-exec transitions
> >   A -- stack_onexec B -- exec apply stack -- A//&B -- exec trans --> C//&D
> > 
> > 3. stack_onexec, stack delayed until exec applied post-exec transitions
> >   A -- stack_onexec B -- exec trans -- C -- apply stack --> C//&B
> > 
> > each is a viable definition and each could have their uses.
> 
> This is perfect; I had been envisioning #2 before this series of emails.
> I didn't like #1 much when I read it in Tyler's proposed manpage. I think
> I prefer #3 now that I've had some time to think about this.

Do you feel like #2 is still useful? I don't want to put words in John's
mouth (so correct me if I'm wrong, John) but I feel like he and I were
focusing on #1 and #3.

I'm struggling to come up with a good use case for #2. I'll go reread
your use cases email and see if one of them feels like a good fit for
#2.

Tyler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20160126/fa78a9cd/attachment.pgp>