On Fri, 2018-02-16 at 16:44 +0200, Vincas Dargis wrote:
> On 2/11/18 11:38 PM, John Johansen wrote:
> > On 02/11/2018 02:42 AM, Vincas Dargis wrote:
> > >
> Now for the Jamie suggestion:
>
> On 2/12/18 7:40 PM, Jamie Strandboge wrote:
> > This is what I initially recommended but based on your
On 02/18/2018 01:42 AM, Vincas Dargis wrote:
> On 2/17/18 8:54 PM, John Johansen wrote:
>> On 02/17/2018 10:11 AM, Vincas Dargis wrote:
>>> That would be fast... I will need to research how to run latest AppArmor or
>>> my (virtual?) machine to work on thought.
>>
>> As long as you don't need a
On 2/17/18 8:54 PM, John Johansen wrote:
On 02/17/2018 10:11 AM, Vincas Dargis wrote:
That would be fast... I will need to research how to run latest AppArmor or my
(virtual?) machine to work on thought.
As long as you don't need a new libapparmor (you shouldn't for these patches)
either
On 02/17/2018 10:11 AM, Vincas Dargis wrote:
> On 2/17/18 8:07 PM, John Johansen wrote:
>>> So the idea is to wait for 3.0 (BETA?) to implement this long-topic NVIDIA
>>> issue then? That would be really nice way, I guess, to fix this in one go,
>>> instead of
On 2/17/18 8:07 PM, John Johansen wrote:
So the idea is to wait for 3.0 (BETA?) to implement this long-topic NVIDIA issue then?
That would be really nice way, I guess, to fix this in one go, instead of
"temporar-stuff-and-real-fix-later".
No the beta won't be a few weeks, I plan to kick out
On 02/17/2018 08:08 AM, Vincas Dargis wrote:
> On 2/17/18 12:12 AM, John Johansen wrote:
>> On 02/16/2018 12:50 PM, Vincas Dargis wrote:
>>> If we stick to this conditionals approach, I believe we are targeting fix
>>> for this NVIDIA issue in no earlier than AppArmor 3.1 I guess?
>>>
>>> This
On 2/17/18 12:12 AM, John Johansen wrote:
On 02/16/2018 12:50 PM, Vincas Dargis wrote:
If we stick to this conditionals approach, I believe we are targeting fix for
this NVIDIA issue in no earlier than AppArmor 3.1 I guess?
This being said, can (and should) we do anything "now", for upcoming
On 02/16/2018 12:50 PM, Vincas Dargis wrote:
> On 2/16/18 10:19 PM, John Johansen wrote:
>> On 02/16/2018 12:09 PM, Vincas Dargis wrote:
>>> $ cat abstractions/nvidia
>>>
>>> if defined $nvidia_strict {
>>> if not $nvidia_strict {
>>> # allow possibly unsafe NVIDIA optimizations, see .
>>>
On 2/16/18 10:19 PM, John Johansen wrote:
On 02/16/2018 12:09 PM, Vincas Dargis wrote:
$ cat abstractions/nvidia
if defined $nvidia_strict {
if not $nvidia_strict {
# allow possibly unsafe NVIDIA optimizations, see .
owner @{HOME}/#[0-9]* rwm,
owner @{HOME}/.glvnd[0-9]* rwm,
On 02/16/2018 12:09 PM, Vincas Dargis wrote:
> On 2/16/18 9:33 PM, John Johansen wrote:
>> On 02/16/2018 06:44 AM, Vincas Dargis wrote:
>>> Could you give example how this tunable + conditional would look like?
>>>
>> see below
>>
>>> Would this be per-machine or per policy decision (probably the
On 2/16/18 9:33 PM, John Johansen wrote:
On 02/16/2018 06:44 AM, Vincas Dargis wrote:
Could you give example how this tunable + conditional would look like?
see below
Would this be per-machine or per policy decision (probably the latter)?
it could be setup either way, it would depend on
On 02/16/2018 06:44 AM, Vincas Dargis wrote:
> On 2/11/18 11:38 PM, John Johansen wrote:
>> On 02/11/2018 02:42 AM, Vincas Dargis wrote:
>>> So to wrap up, plan would be:
>>>
>>> 1. Move `abstactions/nvidia` content into `nvidia-strict`. `nvidia-strict`
>>> should have comment that it does not
On 2/11/18 11:38 PM, John Johansen wrote:
On 02/11/2018 02:42 AM, Vincas Dargis wrote:
So to wrap up, plan would be:
1. Move `abstactions/nvidia` content into `nvidia-strict`. `nvidia-strict`
should have comment that it does not provide some NVIDIA optimizations and some
`deny` rules are
On Sun, 2018-02-11 at 12:42 +0200, Vincas Dargis wrote:
> On 2/8/18 11:25 PM, Jamie Strandboge wrote:
> > >
>
...
> So to wrap up, plan would be:
>
> 1. Move `abstactions/nvidia` content into `nvidia-strict`.
> `nvidia-strict` should have comment that it does not provide some
> NVIDIA
>
On 02/11/2018 02:42 AM, Vincas Dargis wrote:
> On 2/8/18 11:25 PM, Jamie Strandboge wrote:
>>> There is a choice to deny it.
>>
>> Of course. My point was that an nvidia user of the profiled application
>> is going to expect 3d acceleration from the drivers so a profile that
>> is meant to work
On 2/8/18 11:25 PM, Jamie Strandboge wrote:
There is a choice to deny it.
Of course. My point was that an nvidia user of the profiled application
is going to expect 3d acceleration from the drivers so a profile that
is meant to work with nvidia should do that (but see below where I
respond to
On Thu, 2018-02-08 at 19:46 +0200, Vincas Dargis wrote:
> On 2/6/18 9:25 PM, Jamie Strandboge wrote:
> > > Anyway, do we _really_ want to allow mmap on writable files..?
> >
> > Not usually, but in the case of actual shared memory files, there
> > isn't
> > another choice atm. Some day we'll
On 2/6/18 9:25 PM, Jamie Strandboge wrote:
Anyway, do we _really_ want to allow mmap on writable files..?
Not usually, but in the case of actual shared memory files, there isn't
another choice atm. Some day we'll mediate shared memory with non-file
rules[1].
There is a choice to deny it.
On Tue, 2018-02-06 at 20:51 +0200, Vincas Dargis wrote:
> On 2/5/18 11:06 PM, Jamie Strandboge wrote:
> > > Now the question for AppArmor side of affairs, I see two
> > > questions:
> > >
> > > Q1: What's the deal with these /home/vincas/#12976887 paths?
> > > Sysdig
> > > fails to show events
On 2/5/18 11:06 PM, Jamie Strandboge wrote:
Now the question for AppArmor side of affairs, I see two questions:
Q1: What's the deal with these /home/vincas/#12976887 paths? Sysdig
fails to show events for that kind of paths (or I fail to catch
them).
Is is some sort of failure from
On Sun, 2018-02-04 at 13:16 +0200, Vincas Dargis wrote:
> Hi,
>
> I would like to share some info about particular DENIED messages
> that
> happen on the machines with NVIDIA graphics hardware and proprietary
> divers. This does not happen with integrated Intel chips.
>
> You might have seen
21 matches
Mail list logo
