Comment 1 for bug 1620635

I think that the problem here stems from the fact that the home interface's
rules use the "owner" prefix:

 # Allow read access to toplevel $HOME for the user
 owner @{HOME}/ r,

 # Allow read/write access to all non-hidden files that aren't in ~/snap/
 owner @{HOME}/[^s.]** rwk,
 owner @{HOME}/s[^n]** rwk,
 owner @{HOME}/sn[^a]** rwk,
 owner @{HOME}/sna[^p]** rwk,
 # allow creating a few files not caught above
 owner @{HOME}/{s,sn,sna}{,/} rwk,

The kernel tracks these owner permissions differently than permissions that are
not tied to the owner. You can see that the allow vector is not 0x00 with strace:

 $ strace -s1024 ./query_file snap.demo-wget.wget /home/tyhicks/testfile
 ...
 read(3, "allow 0x00000200\ndeny 0x00000000\naudit 0x00000000\nquiet 0x00000000\n", 67) = 67
 ...

The allow vector is non-zero (0x00000200) but it isn't AA_MAY_READ
(0x00000011). Instead, I think AA_MAY_READ is being left shifted by the kernel
to indicate that the "owner" prefix was present on the rule. I'll need to
verify that and then discuss among the upstream developers what to do about
this in the libapparmor query interface.

Additionally, the query_file.c test program has a bug. It redefines
AA_MAY_READ, AA_MAY_WRITE, and AA_CLASS_FILE. It gets the definitions of
AA_MAY_READ and AA_MAY_WRITE wrong. Please just use the definitions provided by
<sys/apparmor.h>.

After making that change, you can remove the "owner" prefix from the rules that
grant access to $HOME in the snap.demo-wget.wget profile, reload the profile,
and then test program will work as expected. This confirms that the "owner" prefix causes the unexpected test program results.