On 07/08/16 09:13, Petr Mladek wrote:
> On Thu 2016-07-07 20:27:13, Topi Miettinen wrote:
>> On 07/07/16 09:16, Petr Mladek wrote:
>>> On Sun 2016-07-03 15:08:07, Topi Miettinen wrote:
The attached patch would make any uses of capabilities generate audit
messages. It works for simple
On 07/08/16 09:13, Petr Mladek wrote:
> On Thu 2016-07-07 20:27:13, Topi Miettinen wrote:
>> On 07/07/16 09:16, Petr Mladek wrote:
>>> On Sun 2016-07-03 15:08:07, Topi Miettinen wrote:
The attached patch would make any uses of capabilities generate audit
messages. It works for simple
On Thu 2016-07-07 20:27:13, Topi Miettinen wrote:
> On 07/07/16 09:16, Petr Mladek wrote:
> > On Sun 2016-07-03 15:08:07, Topi Miettinen wrote:
> >> The attached patch would make any uses of capabilities generate audit
> >> messages. It works for simple tests as you can see from the commit
> >>
On 07/07/16 09:16, Petr Mladek wrote:
> On Sun 2016-07-03 15:08:07, Topi Miettinen wrote:
>> The attached patch would make any uses of capabilities generate audit
>> messages. It works for simple tests as you can see from the commit
>> message, but unfortunately the call to audit_cgroup_list()
On Sun 2016-07-03 15:08:07, Topi Miettinen wrote:
> The attached patch would make any uses of capabilities generate audit
> messages. It works for simple tests as you can see from the commit
> message, but unfortunately the call to audit_cgroup_list() deadlocks the
> system when booting a full
On 06/28/16 04:57, Eric W. Biederman wrote:
> Topi Miettinen writes:
>
>> On 06/24/16 17:21, Eric W. Biederman wrote:
>>> "Serge E. Hallyn" writes:
>>>
Quoting Tejun Heo (t...@kernel.org):
> Hello,
>
> On Fri, Jun 24, 2016 at 10:59:16AM
Topi Miettinen writes:
> On 06/24/16 17:21, Eric W. Biederman wrote:
>> "Serge E. Hallyn" writes:
>>
>>> Quoting Tejun Heo (t...@kernel.org):
Hello,
On Fri, Jun 24, 2016 at 10:59:16AM -0500, Serge E. Hallyn wrote:
> Quoting Tejun Heo
Quoting Tejun Heo (t...@kernel.org):
> Hello,
>
> On Mon, Jun 27, 2016 at 3:10 PM, Topi Miettinen wrote:
> > I'll have to study these more. But from what I saw so far, it looks to
> > me that a separate tool would be needed to read taskstats and if that
> > tool is not taken
Hello,
On Mon, Jun 27, 2016 at 3:10 PM, Topi Miettinen wrote:
> I'll have to study these more. But from what I saw so far, it looks to
> me that a separate tool would be needed to read taskstats and if that
> tool is not taken by distros, the users would not be any wiser,
On 06/27/16 14:54, Serge E. Hallyn wrote:
> Quoting Tejun Heo (t...@kernel.org):
>> Hello, Topi.
>>
>> On Sun, Jun 26, 2016 at 3:14 PM, Topi Miettinen wrote:
>>> The parent might be able do it if proc/pid/xyz files are still
>>> accessible after child exit but before its exit
Quoting Tejun Heo (t...@kernel.org):
> Hello, Topi.
>
> On Sun, Jun 26, 2016 at 3:14 PM, Topi Miettinen wrote:
> > The parent might be able do it if proc/pid/xyz files are still
> > accessible after child exit but before its exit status is collected. But
> > if the parent
Hello, Topi.
On Sun, Jun 26, 2016 at 3:14 PM, Topi Miettinen wrote:
> The parent might be able do it if proc/pid/xyz files are still
> accessible after child exit but before its exit status is collected. But
> if the parent doesn't do it (and you are not able to change it to
On 06/24/16 17:24, Tejun Heo wrote:
> Hello, Serge.
>
> On Fri, Jun 24, 2016 at 11:59:10AM -0500, Serge E. Hallyn wrote:
>>> Just monitoring is less jarring than implementing security enforcement
>>> via cgroup, but it is still jarring. What's wrong with recursive
>>> process hierarchy
On 06/24/16 17:21, Eric W. Biederman wrote:
> "Serge E. Hallyn" writes:
>
>> Quoting Tejun Heo (t...@kernel.org):
>>> Hello,
>>>
>>> On Fri, Jun 24, 2016 at 10:59:16AM -0500, Serge E. Hallyn wrote:
Quoting Tejun Heo (t...@kernel.org):
> But isn't being recursive
On Fri, Jun 24, 2016 at 6:15 AM, Andy Lutomirski wrote:
> On Thu, Jun 23, 2016 at 6:14 PM, Topi Miettinen wrote:
>> On 06/23/16 23:46, Andrew Morton wrote:
>>> On Thu, 23 Jun 2016 18:07:10 +0300 Topi Miettinen
>>> wrote:
>>>
"Serge E. Hallyn" writes:
> Quoting Tejun Heo (t...@kernel.org):
>> Hello,
>>
>> On Fri, Jun 24, 2016 at 10:59:16AM -0500, Serge E. Hallyn wrote:
>> > Quoting Tejun Heo (t...@kernel.org):
>> > > But isn't being recursive orthogonal to using cgroup? Why not account
>> > >
Hello, Serge.
On Fri, Jun 24, 2016 at 11:59:10AM -0500, Serge E. Hallyn wrote:
> > Just monitoring is less jarring than implementing security enforcement
> > via cgroup, but it is still jarring. What's wrong with recursive
> > process hierarchy monitoring which is in line with the whole facility
Quoting Tejun Heo (t...@kernel.org):
> Hello,
>
> On Fri, Jun 24, 2016 at 10:59:16AM -0500, Serge E. Hallyn wrote:
> > Quoting Tejun Heo (t...@kernel.org):
> > > But isn't being recursive orthogonal to using cgroup? Why not account
> > > usages recursively along the process hierarchy?
On Thu, Jun 23, 2016 at 6:14 PM, Topi Miettinen wrote:
> On 06/23/16 23:46, Andrew Morton wrote:
>> On Thu, 23 Jun 2016 18:07:10 +0300 Topi Miettinen wrote:
>>
>>> There are many basic ways to control processes, including capabilities,
>>> cgroups and
On 06/23/16 23:46, Andrew Morton wrote:
> On Thu, 23 Jun 2016 18:07:10 +0300 Topi Miettinen wrote:
>
>> There are many basic ways to control processes, including capabilities,
>> cgroups and resource limits. However, there are far fewer ways to find
>> out useful values for
On 06/23/16 21:38, Tejun Heo wrote:
> Hello,
>
> On Thu, Jun 23, 2016 at 06:07:10PM +0300, Topi Miettinen wrote:
>> There are many basic ways to control processes, including capabilities,
>> cgroups and resource limits. However, there are far fewer ways to find
>> out useful values for the
On Thu, 23 Jun 2016 18:07:10 +0300 Topi Miettinen wrote:
> There are many basic ways to control processes, including capabilities,
> cgroups and resource limits. However, there are far fewer ways to find
> out useful values for the limits, except blind trial and error.
>
>
Hello,
On Thu, Jun 23, 2016 at 06:07:10PM +0300, Topi Miettinen wrote:
> There are many basic ways to control processes, including capabilities,
> cgroups and resource limits. However, there are far fewer ways to find
> out useful values for the limits, except blind trial and error.
>
>
On Thu, Jun 23, 2016 at 8:07 AM, Topi Miettinen wrote:
> There are many basic ways to control processes, including capabilities,
> cgroups and resource limits. However, there are far fewer ways to find
> out useful values for the limits, except blind trial and error.
>
>
There are many basic ways to control processes, including capabilities,
cgroups and resource limits. However, there are far fewer ways to find
out useful values for the limits, except blind trial and error.
Currently, there is no way to know which capabilities are actually used.
Even the source
25 matches
Mail list logo