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

John Johansen john.johansen at canonical.com
Wed Jan 27 15:29:26 UTC 2016


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.




More information about the AppArmor mailing list