On Thu, Sep 13, 2018 at 11:47:40 -0500, Jason Crain wrote: > My understanding is that this limitation is in the Linux kernel's > security module framework. Symbolic links are resolved before AppArmor > can verify permission for the path, so AppArmor only sees > "/xr0/michael/...etc...", not "/home/michael/...etc...".
That makes some sense. It would be reasonable to set different security policies on different filesystems--even directories within a filesystem, when fs.protected_hardlinks is in use. $HOME vs. /xr0 is only part of the problem. The apparmor rules say that evince can open: * any file under $HOME * any file outside of $HOME named *.pdf What is actually triggering the denial is that the target git-annex path has no extension. I don't understand the security benefit, because: * the symlink, its target, and both directories are owned by me and not writable by anyone else * anyone trying to exploit users will simply give the file the expected extension (otherwise people would have trouble opening it) * harmful files are most likely to be in web/mail download directories, which are probably under $HOME so don't even get the extension check -- Michael
signature.asc
Description: PGP signature