shell's test gives false positive on readability of files

[Marco Trevisan (Treviño)]

If inside any snap run --shell I do:

test -r /home/$USER/.bashrc && echo true

The output is true, although I'm not able to read that file... Of course I can't get its content and thus sandbox works, but it would be nice to be able to check this properly using standard sh tools (I'm using something like `head -c0 /home/$USER/out.ogv &> /dev/null && echo true`).

[Maciej Borzecki (maciek-borzecki)]

My guess would be that `test` does a stat() and checks st_mode against provided flags, so it's like only reading the metadata. The actual blocking/sandboxing happens on calls that have side effects on the real data, eg. open().

[Seth Arnold (seth-arnold)]

AppArmor intentionally does not mediate access(2) and similar system calls. While it might be feasible to give results for files, giving results for a directory would be error-prone.

We chose to err on the side of saying access(2) does not reflect AppArmor's mediation for the simplicity of the mental model.

Thanks

[Zygmunt Krynicki (zyga)]

As was explained above apparmor and the sandbox in general doesn't pretend to change UNIX permissions that access(2) is based on. Unless we plan to do library or syscall intercepts I don't think we can fix it.