[Apparmor-general] usr.X11R6.bin.acroread causes error message

[jesse michael]

On Fri, Jan 12, 2007 at 02:51:22PM +1100, Crispin Cowan wrote:
> >> Jan  6 03:14:44 linux kernel: SubDomain: REJECTING link access 
> >> from /home/malte_gell/.adobe/Acrobat/7.0/Cert/curl-ca-bundle.crt to
> >>  /usr/X11R6/lib/Acrobat7/Reader/Cert/curl-ca-bundle.crt (acroread(32553) 
> >> profile /usr/X11R6/bin/acroread active /usr/X11R6/bin/acr
> >> oread)
> >>     
> > currently AA requires that
> > 1. link being created has the l permission
> > 2. the link and the target of the link have the same AA permissions
> >    (excluding the link permission)
> >
> > in this case 1. is satisfied but the link only has rw while the target
> > has mixr, so AA won't allow this link to be created.
> >   
> Hmmm. Normally, "just run logprof" is the way to get permissions
> corrected so that AA will allow the rejected action. Logprof should see
> the REJECT message and suggest amending permissions to allow what was
> just blocked. But is logprof smart enough to figure this one out? Can it
> discover that the problem is in the permissions mismatch between the
> source rule and the destination rule?

logprof currently gets this wrong because it thinks that a superset of the
required permissions is sufficient when it has to be exact-match instead.

the exact-match requirement is a little unfortunate for the case where you
have rules like--

  /home/*/.adobe/** rwl,
  /usr/X11R6/lib/Acrobat7/Reader/** r,

because the permission for the files in the home directory has an additional
w bit, creating links that point at the system directory will cause REJECT
messages and the answer is to either (1) delete the "w" bit from the /home 
rule or (2) add a "w" bit to the /usr rule.  

going with option 1 will cause problems when the app wants to update config
files in .adobe, but going with option 2 means that you're granting write 
access to the system directory.  ick.