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
On Thu, Sep 13, 2018 at 16:22:03 +0200, Antonio Ospite wrote:
> I am not the maintainer or anything, but I am curios, what are the
> permissions of the _destination_ file?
>
> I mean, what does "ls -l --dereference meltdown.pdf" say?
-r 1 michael michael 188549 Jan 27 2018 meltdown.pdf
On 2018-01-27, Michael Gold wrote:
> The problem seems to be that the file isn't treated as being under $HOME
> and isn't treated as having a ".pdf" suffix. Both are true for the name
> being opened, but not for the target.
My understanding is that this limitation is in the Linux kernel's
Package: evince
Followup-For: Bug #888620
Dear OP,
I am not the maintainer or anything, but I am curios, what are the
permissions of the _destination_ file?
I mean, what does "ls -l --dereference meltdown.pdf" say?
Ciao,
Antonio
-- System Information:
Debian Release: buster/sid
APT
Package: evince
Version: 3.26.0-2
A recent kernel upgrade pulled in AppArmor, after which I was no longer
able to view (some) PDF files in git-annex repositories. For example:
$ cd
$ pwd -P
/home/michael
$ cd ~/x
$ mkdir git-annex-test
$ cd
5 matches
Mail list logo
