Merge Small fixes to libapparmor man pages, including type signature fix

These are small changes to the man pages, with the most important one being updating some function signatures to be consistent with apparmor.h.

We should put together a man page for aalogparse functions too, but I'm submitting this MR first to get the smaller changes in faster.

Signed-off-by: Ryan Lee <ryan.lee@canonical.com>

MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1378
Approved-by: Christian Boltz <apparmor@cboltz.de>
Merged-by: Ryan Lee <rlee287@yahoo.com>

libraries/libapparmor/doc/aa_change_hat.pod

@@ -22,15 +22,15 @@
 
 =head1 NAME
 
-aa_change_hat  - change to or from a "hat" within a AppArmor profile
+aa_change_hat - change to or from a "hat" within a AppArmor profile
 
 =head1 SYNOPSIS
 
 B<#include E<lt>sys/apparmor.hE<gt>>
 
-B<int aa_change_hat (char *subprofile, unsigned long magic_token);>
+B<int aa_change_hat (const char *subprofile, unsigned long magic_token);>
 
-B<int aa_change_hatv (char *subprofiles[], unsigned long magic_token);>
+B<int aa_change_hatv (const char *subprofiles[], unsigned long magic_token);>
 
 B<int aa_change_hat_vargs (unsigned long magic_token, ...);>
 

libraries/libapparmor/doc/aa_change_profile.pod

@@ -22,7 +22,7 @@
 
 =head1 NAME
 
-aa_change_profile, aa_change_onexec - change a tasks profile
+aa_change_profile, aa_change_onexec - change a task's profile
 
 =head1 SYNOPSIS
 
@@ -58,8 +58,8 @@ The aa_change_onexec() function is like the aa_change_profile() function
 except it specifies that the profile transition should take place on the
 next exec instead of immediately.  The delayed profile change takes
 precedence over any exec transition rules within the confining profile.
-Delaying the profile boundary has a couple of advantages, it removes the
-need for stub transition profiles and the exec boundary is a natural security
+Delaying the profile boundary has a couple of advantages: it removes the
+need for stub transition profiles, and the exec boundary is a natural security
 layer where potentially sensitive memory is unmapped.
 
 =head1 RETURN VALUE

libraries/libapparmor/doc/aa_features.pod

@@ -54,7 +54,7 @@ B<typedef struct aa_features aa_features;>
 
 B<int aa_features_new(aa_features **features, int dirfd, const char *path);>
 
-B<int aa_features_new_from_file(aa_features **features, int fd);>
+B<int aa_features_new_from_file(aa_features **features, int file);>
 
 B<int aa_features_new_from_string(aa_features **features, const char *string, size_t size);>
 

libraries/libapparmor/doc/aa_find_mountpoint.pod

@@ -58,6 +58,9 @@ appropriately.
 
 =head1 ERRORS
 
+# podchecker warns about duplicate link targets for EACCES, EBUSY, ENOENT,
+# and ENOMEM, but this is a warning that is safe to ignore.
+
 B<aa_is_enabled>
 
 =over 4

libraries/libapparmor/doc/aa_stack_profile.pod

@@ -41,7 +41,7 @@ result is an intersection of all profiles which are stacked. Stacking profiles
 together is desirable when wanting to ensure that confinement will never become
 more permissive. When changing between two profiles, as performed with
 aa_change_profile(2), there is always the possibility that the new profile is
-more permissive than the old profile but that possibility is eliminated when
+more permissive than the old profile, but that possibility is eliminated when
 using aa_stack_profile().
 
 To stack a profile with the current confinement context, a task can use the
@@ -68,7 +68,7 @@ The aa_stack_onexec() function is like the aa_stack_profile() function
 except it specifies that the stacking should take place on the next exec
 instead of immediately. The delayed profile change takes precedence over any
 exec transition rules within the confining profile. Delaying the stacking
-boundary has a couple of advantages, it removes the need for stub transition
+boundary has a couple of advantages: it removes the need for stub transition
 profiles and the exec boundary is a natural security layer where potentially
 sensitive memory is unmapped.