[apparmor] [PATCH 3/3] libapparmor: Correct meaning of EPERM in aa_change_profile man page

[Tyler Hicks]

On 2016-01-27 07:29:26, John Johansen wrote:
> On 01/26/2016 04:18 PM, Tyler Hicks wrote:
> > I suspect that the incorrect description of EPERM was copied from
> > the aa_change_hat man page, where it is possible to see EPERM if the
> > application is not confined by AppArmor.
> > 
> > This patch corrects the description by documenting that the only
> > possible way to see EPERM is if a confined application has the
> > no_new_privs bit set.
> > 
> > Signed-off-by: Tyler Hicks <tyhicks at canonical.com>
> > Reported-by: Seth Arnold <seth.arnold at canonical.com>
> > ---
> >  libraries/libapparmor/doc/aa_change_profile.pod | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/libraries/libapparmor/doc/aa_change_profile.pod b/libraries/libapparmor/doc/aa_change_profile.pod
> > index 3cad427..c9121fe 100644
> > --- a/libraries/libapparmor/doc/aa_change_profile.pod
> > +++ b/libraries/libapparmor/doc/aa_change_profile.pod
> > @@ -83,8 +83,8 @@ Insufficient kernel memory was available.
> >  
> >  =item B<EPERM>
> >  
> > -The calling application is not confined by apparmor, or the no_new_privs
> > -bit is set.
> > +The calling application is confined by apparmor and the no_new_privs bit is
> > +set.
> >  
> 
> This reminded me of another bit for the stacking discussion, my current plan
> is no_new_privs will not block plain stacking.  That is if you are confined by
> A and stack B onto it to have a confinement of A//&B, will be allowed as it
> is a guarenteed subset. However a transition that stacks say A going to C//&B
> will get blocked.

That sounds reasonable to me.

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/20160127/655ca4ae/attachment.pgp>