Package: libreoffice-common
Version: 1:7.3.0~rc2-2
Severity: normal
Tags: upstream
Dear Maintainer,
Looks like bug #905442 is back. We need rule with eight (and more) question
marks:
type=AVC msg=audit(1642615553.674:2636): apparmor="DENIED"
operation="mknod" profile="libreoffice-soffice"
name="
2021-03-09 20:40, Rene Engelhard rašė:
I've looked at the
https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/commit/03ba395bbe21154efc8a05dfbb9f7c16946eb4d2
diff linked in one of the posts and I see 11 question marks, not 9.
> Hmm, indeed. My bad.
That means we need to do some
2021-03-08 21:51, Rene Engelhard wrote:
Yes, it is done.
In 7.1. As the version tracking info clearly showed.
Ouch.. I've missed the version number, sorry...
Changing rule into this:
owner @{libo_user_dirs}/{,**/}lu?{,?,??}.tmp rwk, #Temporary
file used when saving
Did the trick (n
Control: reopen -1
I see this bug marked as Done but I just got denial today:
type=AVC msg=audit(1615225628.771:1363): apparmor="DENIED" operation="mknod" profile="libreoffice-soffice"
name="/home/vincas/Dokumentai/lu4638vdjw1.tmp" pid=4638 comm="soffice.bin" requested_mask="c" denied_mask="c"
Control: user pkg-apparmor-t...@lists.alioth.debian.org
Control: usertag -1 +modify-profile
Also Rene, please add usertag for any AppArmor-related bug, so AppArmor team
could see what's going on.
Hi,
I too seen these /tmp/xauth.. stuff (I'm KDE user), and asked about it in AppArmor mailing list [0],
and later in debian-devel [1].
Nothing new since when, haven given it any more time, but what I would like to achieve is as
"agreement", that if some Debian package changes some "popular"
We have now mesa abstraction in Buster that fixes this bug... but so what? I guess I'll have to add
yet another [0] backport to upstream profile because it exists not only for Buster...
I am thinking to propose LibreOffice upstream to split profile into apparmor-x.yz directories to
match polici
n 8/7/18 1:55 PM, Rene Engelhard wrote:
Sorry, apparently didn't read fully the first time I read this mail.
Really $HOME? I would be surprised.
I know there's lu??.tmps in /tmp (or $TMPDIR) but $HOME?
Did you set TMPDIR=$HOME?
No, TMPDIR is not set. LO additionally tries to save .tmp
On 8/6/18 11:54 PM, Rene Engelhard wrote:
On Sat, Aug 04, 2018 at 05:50:35PM +0300, Vincas Dargis wrote:
BTW I have proposed update to use `dri-enumerate` abstraction and remove
backported rule:
https://gerrit.libreoffice.org/#/c/58589/
As I said upstream I am not sure about this upstream
On Sat, 04 Aug 2018 23:21:19 +0800 intrigeri wrote:
> BTW I have proposed update to use `dri-enumerate` abstraction and remove
backported rule:
> https://gerrit.libreoffice.org/#/c/58589/
If I'm supposed to act on this, please clarify what I should do,
otherwise ignore this sentence.
Sorry f
Package: libreoffice-common
Version: 1:6.1.0~rc2-3
Severity: normal
Tags: upstream
Dear Maintainer,
I cannot save files when AppArmor profile is in enforce mode:
```
type=AVC msg=audit(1533396515.983:974): apparmor="DENIED"
operation="mknod" profile="libreoffice-soffice"
name="/home/vincas/lu279
On 8/4/18 6:22 PM, intrigeri wrote:
or else maybe we could backport `mesa` abstraction into AppArmor
2.13?
Why not. Create a MR or file a bug against src:apparmor?
Cool, I will work on MR. "Why not" could be "don't want to manage backports too
much" :) .
intrigeri, are we getting AppArmor 3 in Buster, or else maybe we could backport `mesa` abstraction
into AppArmor 2.13?
intrigeri, could we get opencl abstractions in 2.13, or we are expecting to get
AppArmor 3 in Buster?
BTW I have proposed update to use `dri-enumerate` abstraction and remove
backported rule:
https://gerrit.libreoffice.org/#/c/58589/
Package: libreoffice-common
Version: 1:6.1.0~rc2-3
Severity: normal
Tags: upstream
User: pkg-apparmor-t...@lists.alioth.debian.org
Usertags: modify-profile
Dear Maintainer,
I got this deny:
```
type=AVC msg=audit(1533391970.983:584): apparmor="DENIED" operation="open"
profile="libreoffice-soffi
On 3/4/18 1:52 PM, Rene Engelhard wrote:
Tools->Options-OpenCL. Though that setting doesn't persist here,
probably because LO notices I don't have a working OpenCL config..
After some testing, it seems that OpenCL option persist for me only if I
launch LO through `optirun` command, that enable
On 3/4/18 1:52 PM, Rene Engelhard wrote:
On Sat, Mar 03, 2018 at 03:10:45PM +0200, Vincas Dargis wrote:
I'm on switching laptop (Intel + NVIDIA). Maybe I have to enable OpenCL for
Libreoffice somehow?
Tools->Options-OpenCL. Though that setting doesn't persist here,
probably becau
On Fri, 16 Feb 2018 08:48:06 -0700 Thomas Vaughan
wrote:
I see that this bug is closed, but I see something similar in my
system log. I am running Debian unstable updated as of yesterday. It
seems that libreoffice is trying to make use of OpenCL, and I have a
couple of OpenCL ICDs installed.
On 2/16/18 8:08 PM, Rene Engelhard wrote:
On Fri, Feb 16, 2018 at 08:48:06AM -0700, Thomas Vaughan wrote:
Feb 15 17:41:31 foo-machine kernel: [85508.697711] kauditd_printk_skb:
8 callbacks suppressed
Feb 15 17:41:31 foo-machine kernel: [85508.697712] audit: type=1400
audit(1518741691.452:20): ap
On 2018-01-21 20:33, Rene Engelhard wrote:
Want to do a MR or should I just backport the patch myself?
I would like to try to backport it within upcoming week.
https://gerrit.libreoffice.org/#/c/48265/
For the record, these */uevent files are accessed by libdrm
Here's breakpoint while opening `/sys/dev/char/226:0/device/ueven` file:
```
Thread 2.1 "soffice.bin" hit Catchpoint 1 (call to syscall openat), 0x7fa253f6961e in __libc_open64
(file=0x7ffe077e8900 "/sys/dev/char/226:0/device/ueven
On 2017-11-28 12:19, intrigeri wrote:
→ In this case, I would argue that we're talking about a corner
case, that only rather advanced users will hit, and I find it sad
that everyone else can't benefit from AppArmor security benefits
due to that, so I'm leaning towards:
23 matches
Mail list logo
