Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1430194 > unrolled thread

Re: [PATCH] capabilities: add capability cgroup controller

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] capabilities: add capability cgroup controller Tejun Heo <tj@kernel.org> - 2016-06-23 23:40 +0200
    Re: [PATCH] capabilities: add capability cgroup controller Topi Miettinen <toiwoton@gmail.com> - 2016-06-24 02:30 +0200
      Re: [PATCH] capabilities: add capability cgroup controller Tejun Heo <tj@kernel.org> - 2016-06-24 17:50 +0200
        Re: [PATCH] capabilities: add capability cgroup controller "Serge E. Hallyn" <serge@hallyn.com> - 2016-06-24 18:00 +0200
          Re: [PATCH] capabilities: add capability cgroup controller Tejun Heo <tj@kernel.org> - 2016-06-24 18:40 +0200
            Re: [PATCH] capabilities: add capability cgroup controller "Serge E. Hallyn" <serge@hallyn.com> - 2016-06-24 19:00 +0200
              Re: [PATCH] capabilities: add capability cgroup controller Tejun Heo <tj@kernel.org> - 2016-06-24 19:30 +0200
                Re: [PATCH] capabilities: add capability cgroup controller Topi Miettinen <toiwoton@gmail.com> - 2016-06-26 21:20 +0200
                  Re: [PATCH] capabilities: add capability cgroup controller Tejun Heo <tj@kernel.org> - 2016-06-27 00:30 +0200
                    Re: [PATCH] capabilities: add capability cgroup controller "Serge E. Hallyn" <serge@hallyn.com> - 2016-06-27 17:00 +0200
                      Re: [PATCH] capabilities: add capability cgroup controller Tejun Heo <tj@kernel.org> - 2016-06-27 21:20 +0200
                        Re: [PATCH] capabilities: add capability cgroup controller "Serge E. Hallyn" <serge@hallyn.com> - 2016-06-27 21:50 +0200
                          Re: [PATCH] capabilities: add capability cgroup controller Topi Miettinen <toiwoton@gmail.com> - 2016-07-03 17:10 +0200
                            Re: [PATCH] capabilities: audit capability use kbuild test robot <lkp@intel.com> - 2016-07-03 18:20 +0200
                            Re: [PATCH] capabilities: add capability cgroup controller Petr Mladek <pmladek@suse.com> - 2016-07-07 11:20 +0200
                              Re: [PATCH] capabilities: add capability cgroup controller Topi Miettinen <toiwoton@gmail.com> - 2016-07-07 22:30 +0200
                                Re: [PATCH] capabilities: add capability cgroup controller Petr Mladek <pmladek@suse.com> - 2016-07-08 11:20 +0200
                                  Re: [PATCH] capabilities: add capability cgroup controller Topi Miettinen <toiwoton@gmail.com> - 2016-07-09 18:40 +0200
                      Re: [PATCH] capabilities: add capability cgroup controller Topi Miettinen <toiwoton@gmail.com> - 2016-06-27 21:20 +0200
              Re: [PATCH] capabilities: add capability cgroup controller ebiederm@xmission.com (Eric W. Biederman) - 2016-06-24 19:40 +0200
                Re: [PATCH] capabilities: add capability cgroup controller "Serge E. Hallyn" <serge@hallyn.com> - 2016-06-24 19:50 +0200
                Re: [PATCH] capabilities: add capability cgroup controller Topi Miettinen <toiwoton@gmail.com> - 2016-06-26 21:10 +0200
                  Re: [PATCH] capabilities: add capability cgroup controller ebiederm@xmission.com (Eric W. Biederman) - 2016-06-28 07:10 +0200
                    Re: [PATCH] capabilities: add capability cgroup controller Topi Miettinen <toiwoton@gmail.com> - 2016-07-02 13:30 +0200

Page 1 of 2  [1] 2  Next page →

#1430194 — Re: [PATCH] capabilities: add capability cgroup controller

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.
> 
> Currently, there is no way to know which capabilities are actually used.
> Even the source code is only implicit, in-depth knowledge of each
> capability must be used when analyzing a program to judge which
> capabilities the program will exercise.
> 
> Add a new cgroup controller for monitoring of capabilities
> in the cgroup.
> 
> Test case demonstrating basic capability monitoring and how the
> capabilities are combined at next level (boot to rdshell):

This doesn't have anything to do with resource control and I don't
think it's a good idea to add arbitrary monitoring mechanisms to
cgroup just because it's easy to add interface there.  Given that
capabilities are inherited and modified through the process hierarchy,
shouldn't this be part of that?

Thanks.

-- 
tejun

[toc] | [next] | [standalone]

#1430257

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 limits, except blind trial and error.
>>
>> Currently, there is no way to know which capabilities are actually used.
>> Even the source code is only implicit, in-depth knowledge of each
>> capability must be used when analyzing a program to judge which
>> capabilities the program will exercise.
>>
>> Add a new cgroup controller for monitoring of capabilities
>> in the cgroup.
>>
>> Test case demonstrating basic capability monitoring and how the
>> capabilities are combined at next level (boot to rdshell):
> 
> This doesn't have anything to do with resource control and I don't
> think it's a good idea to add arbitrary monitoring mechanisms to
> cgroup just because it's easy to add interface there.  Given that
> capabilities are inherited and modified through the process hierarchy,
> shouldn't this be part of that?

With per process tracking, it's easy to miss if a short-lived process
exercised capabilities. Especially with ambient capabilities, the parent
process could be a shell script which might not use capabilities at all,
but its children do the heavy lifting.

Per process tracking (like in the version I sent earlier) could still be
added on top of this to complement cgroup level tracking, but I think
cgroup approach is more flexible as it can cover anything from a single
task to a collection of processes.

-Topi

> 
> Thanks.
> 

[toc] | [prev] | [next] | [standalone]

#1430774

Hello,

On Fri, Jun 24, 2016 at 12:22:54AM +0000, Topi Miettinen wrote:
> > This doesn't have anything to do with resource control and I don't
> > think it's a good idea to add arbitrary monitoring mechanisms to
> > cgroup just because it's easy to add interface there.  Given that
> > capabilities are inherited and modified through the process hierarchy,
> > shouldn't this be part of that?
> 
> With per process tracking, it's easy to miss if a short-lived process
> exercised capabilities. Especially with ambient capabilities, the parent
> process could be a shell script which might not use capabilities at all,
> but its children do the heavy lifting.

But isn't being recursive orthogonal to using cgroup?  Why not account
usages recursively along the process hierarchy?  Capabilities don't
have much to do with cgroup but everything with process hierarchy.
That's how they're distributed and modified.  If monitoring their
usages is necessary, it makes sense to do it in the same structure.

Thanks.

-- 
tejun

[toc] | [prev] | [next] | [standalone]

#1430781

Quoting Tejun Heo (tj@kernel.org):
> Hello,
> 
> On Fri, Jun 24, 2016 at 12:22:54AM +0000, Topi Miettinen wrote:
> > > This doesn't have anything to do with resource control and I don't
> > > think it's a good idea to add arbitrary monitoring mechanisms to
> > > cgroup just because it's easy to add interface there.  Given that
> > > capabilities are inherited and modified through the process hierarchy,
> > > shouldn't this be part of that?
> > 
> > With per process tracking, it's easy to miss if a short-lived process
> > exercised capabilities. Especially with ambient capabilities, the parent
> > process could be a shell script which might not use capabilities at all,
> > but its children do the heavy lifting.
> 
> But isn't being recursive orthogonal to using cgroup?  Why not account
> usages recursively along the process hierarchy?  Capabilities don't
> have much to do with cgroup but everything with process hierarchy.
> That's how they're distributed and modified.  If monitoring their
> usages is necessary, it makes sense to do it in the same structure.

That was my argument against using cgroups to enforce a new bounding
set.  For tracking though, the cgroup process tracking seems as applicable
to this as it does to systemd tracking of services.  It tracks a task and
the children it forks.

[toc] | [prev] | [next] | [standalone]

#1430798

Hello,

On Fri, Jun 24, 2016 at 10:59:16AM -0500, Serge E. Hallyn wrote:
> Quoting Tejun Heo (tj@kernel.org):
> > But isn't being recursive orthogonal to using cgroup?  Why not account
> > usages recursively along the process hierarchy?  Capabilities don't
> > have much to do with cgroup but everything with process hierarchy.
> > That's how they're distributed and modified.  If monitoring their
> > usages is necessary, it makes sense to do it in the same structure.
> 
> That was my argument against using cgroups to enforce a new bounding
> set.  For tracking though, the cgroup process tracking seems as applicable
> to this as it does to systemd tracking of services.  It tracks a task and
> the children it forks.

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
is implemented anyway?

Thanks.

-- 
tejun

[toc] | [prev] | [next] | [standalone]

#1430813

Quoting Tejun Heo (tj@kernel.org):
> Hello,
> 
> On Fri, Jun 24, 2016 at 10:59:16AM -0500, Serge E. Hallyn wrote:
> > Quoting Tejun Heo (tj@kernel.org):
> > > But isn't being recursive orthogonal to using cgroup?  Why not account
> > > usages recursively along the process hierarchy?  Capabilities don't
> > > have much to do with cgroup but everything with process hierarchy.
> > > That's how they're distributed and modified.  If monitoring their
> > > usages is necessary, it makes sense to do it in the same structure.
> > 
> > That was my argument against using cgroups to enforce a new bounding
> > set.  For tracking though, the cgroup process tracking seems as applicable
> > to this as it does to systemd tracking of services.  It tracks a task and
> > the children it forks.
> 
> 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
> is implemented anyway?

As I think Topi pointed out, one shortcoming is that if there is a short-lived
child task, using its /proc/self/status is racy.  You might just miss that it
ever even existed, let alone that the "application" needed it.

Another alternative we've both mentioned is to use systemtap.  That's not
as nice a solution as a cgroup, but then again this isn't really a common
case, so maybe it is precisely what a tracing infrastructure is meant for.

-serge

[toc] | [prev] | [next] | [standalone]

#1430827

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
> > is implemented anyway?
> 
> As I think Topi pointed out, one shortcoming is that if there is a short-lived
> child task, using its /proc/self/status is racy.  You might just miss that it
> ever even existed, let alone that the "application" needed it.

But the parent can collect whatever its children used.  We already do
that with other stats.

Thanks.

-- 
tejun

[toc] | [prev] | [next] | [standalone]

#1431562

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 monitoring which is in line with the whole facility
>>> is implemented anyway?
>>
>> As I think Topi pointed out, one shortcoming is that if there is a short-lived
>> child task, using its /proc/self/status is racy.  You might just miss that it
>> ever even existed, let alone that the "application" needed it.
> 
> But the parent can collect whatever its children used.  We already do
> that with other stats.

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 do it)
and it collects the exit status without collecting other info, can you
suggest a different way how another process could collect it 100% reliably?

-Topi

> 
> Thanks.
> 

[toc] | [prev] | [next] | [standalone]

#1431630

Hello, Topi.

On Sun, Jun 26, 2016 at 3:14 PM, Topi Miettinen <toiwoton@gmail.com> 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 do it)
> and it collects the exit status without collecting other info, can you
> suggest a different way how another process could collect it 100% reliably?

I'm not saying that there's such mechanism now. I'm suggesting that
that'd be a more fitting way of implementing a new mechanism to track
capability usages.

Thanks.

-- 
tejun

[toc] | [prev] | [next] | [standalone]

#1432101

Quoting Tejun Heo (tj@kernel.org):
> Hello, Topi.
> 
> On Sun, Jun 26, 2016 at 3:14 PM, Topi Miettinen <toiwoton@gmail.com> 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 do it)
> > and it collects the exit status without collecting other info, can you
> > suggest a different way how another process could collect it 100% reliably?
> 
> I'm not saying that there's such mechanism now. I'm suggesting that
> that'd be a more fitting way of implementing a new mechanism to track
> capability usages.

Hi Topi,

I think Eric was right a few emails earlier that the audit subsystem is
really the most appropriate answer to this.  (Perhaps sysctl-controllered?)
Combined with taskstats it would give you what you need.  Or you could even
use an empty new named cgroup controller, say 'none,name=caps', and then
look only at audit results for cgroup '/myapp' in the caps hierarchy.

[toc] | [prev] | [next] | [standalone]

#1432233

Hello,

On Mon, Jun 27, 2016 at 3:10 PM, Topi Miettinen <toiwoton@gmail.com> 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, right?
> With cgroup (or /proc), no new tools would be needed.

That is a factor but shouldn't be a deciding factor in designing our
user-facing interfaces. Please also note that kernel source tree
already has tools/ subdirectory which contains userland tools which
are distributed along with the kernel.

Thanks.

-- 
tejun

[toc] | [prev] | [next] | [standalone]

#1432279

Quoting Tejun Heo (tj@kernel.org):
> Hello,
> 
> On Mon, Jun 27, 2016 at 3:10 PM, Topi Miettinen <toiwoton@gmail.com> 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, right?
> > With cgroup (or /proc), no new tools would be needed.
> 
> That is a factor but shouldn't be a deciding factor in designing our
> user-facing interfaces. Please also note that kernel source tree
> already has tools/ subdirectory which contains userland tools which
> are distributed along with the kernel.

And, if you take audit+cgroup approach then no tools are needed.  So long
as you can have audit print out the cgroups for a task as part of the
capability audit record.

[toc] | [prev] | [next] | [standalone]

#1435970

[Multipart message — attachments visible in raw view] — view raw

On 06/27/16 19:49, Serge E. Hallyn wrote:
> Quoting Tejun Heo (tj@kernel.org):
>> Hello,
>>
>> On Mon, Jun 27, 2016 at 3:10 PM, Topi Miettinen <toiwoton@gmail.com> 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, right?
>>> With cgroup (or /proc), no new tools would be needed.
>>
>> That is a factor but shouldn't be a deciding factor in designing our
>> user-facing interfaces. Please also note that kernel source tree
>> already has tools/ subdirectory which contains userland tools which
>> are distributed along with the kernel.
> 
> And, if you take audit+cgroup approach then no tools are needed.  So long
> as you can have audit print out the cgroups for a task as part of the
> capability audit record.
> 

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 blown OS. There's no deadlock when the call
is removed.

I guess that in some cases, cgroup_mutex and/or css_set_lock could be
already held earlier before entering audit_cgroup_list(). Holding the
locks is however required by task_cgroup_from_root(). Is there any way
to avoid this? For example, only print some kind of cgroup ID numbers
(are there unique and stable IDs, available without locks?) for those
cgroups where the task is registered in the audit message?

I could remove the cgroup part from the audit message entirely, but then
knowing which capabilities were used in what cgroup gets much more
difficult. The rest of the patch would be useful without it and of
course simpler.

In my earlier versions a per-task cap_used variable summarized all uses
of capabilities, but it was not clear when to reset the variable (fork?
exec? capset?), so it's gone for now. This was also used to rate limit
printing audit messages by only acting when each capability was first
used by the task, but now all uses of capabilities trigger audit
logging. Could that become a problem? I think it only makes sense to
summarize capability use per cgroup (via taskstats).

-Topi

[toc] | [prev] | [next] | [standalone]

#1435979 — Re: [PATCH] capabilities: audit capability use

[Multipart message — attachments visible in raw view] — view raw

Hi,

[auto build test ERROR on cgroup/for-next]
[also build test ERROR on v4.7-rc5]
[cannot apply to next-20160701]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Topi-Miettinen/capabilities-audit-capability-use/20160703-231120
base:   https://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-next
config: microblaze-mmu_defconfig (attached as .config)
compiler: microblaze-linux-gcc (GCC) 4.9.0
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=microblaze 

All errors (new ones prefixed by >>):

>> kernel/audit.c:1713:6: error: redefinition of 'audit_log_cap_use'
    void audit_log_cap_use(int cap)
         ^
   In file included from kernel/audit.c:59:0:
   include/linux/audit.h:574:20: note: previous definition of 'audit_log_cap_use' was here
    static inline void audit_log_cap_use(int cap)
                       ^
   kernel/audit.c: In function 'audit_log_cap_use':
>> kernel/audit.c:1730:2: error: implicit declaration of function 'audit_cgroup_list' [-Werror=implicit-function-declaration]
     audit_cgroup_list(ab);
     ^
   cc1: some warnings being treated as errors

vim +/audit_log_cap_use +1713 kernel/audit.c

  1707	
  1708		if (log)
  1709			audit_log_format(ab, " cap_fe=%d cap_fver=%x",
  1710					 name->fcap.fE, name->fcap_ver);
  1711	}
  1712	
> 1713	void audit_log_cap_use(int cap)
  1714	{
  1715		struct audit_context *context = current->audit_context;
  1716		struct audit_buffer *ab;
  1717		kuid_t uid;
  1718		kgid_t gid;
  1719	
  1720		ab = audit_log_start(context, GFP_KERNEL, AUDIT_CAPABILITY);
  1721		audit_log_format(ab, "cap_used=%d", cap);
  1722		current_uid_gid(&uid, &gid);
  1723		audit_log_format(ab, " pid=%d auid=%u uid=%u gid=%u ses=%u",
  1724				 task_pid_nr(current),
  1725				 from_kuid(&init_user_ns, audit_get_loginuid(current)),
  1726				 from_kuid(&init_user_ns, uid),
  1727				 from_kgid(&init_user_ns, gid),
  1728				 audit_get_sessionid(current));
  1729		audit_log_format(ab, " cgroups=");
> 1730		audit_cgroup_list(ab);
  1731		audit_log_end(ab);
  1732	}
  1733	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[toc] | [prev] | [next] | [standalone]

#1438429

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 blown OS. There's no deadlock when the call
> is removed.
> 
> I guess that in some cases, cgroup_mutex and/or css_set_lock could be
> already held earlier before entering audit_cgroup_list(). Holding the
> locks is however required by task_cgroup_from_root(). Is there any way
> to avoid this? For example, only print some kind of cgroup ID numbers
> (are there unique and stable IDs, available without locks?) for those
> cgroups where the task is registered in the audit message?

I am not sure if anyone know what really happens here. I suggest to
enable lockdep. It might detect possible deadlock even before it
really happens, see Documentation/locking/lockdep-design.txt

It can be enabled by

   CONFIG_PROVE_LOCKING=y

It depends on

    CONFIG_DEBUG_KERNEL=y

and maybe some more options, see lib/Kconfig.debug


Best Regards,
Petr

[toc] | [prev] | [next] | [standalone]

#1438921

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() deadlocks the
>> system when booting a full blown OS. There's no deadlock when the call
>> is removed.
>>
>> I guess that in some cases, cgroup_mutex and/or css_set_lock could be
>> already held earlier before entering audit_cgroup_list(). Holding the
>> locks is however required by task_cgroup_from_root(). Is there any way
>> to avoid this? For example, only print some kind of cgroup ID numbers
>> (are there unique and stable IDs, available without locks?) for those
>> cgroups where the task is registered in the audit message?
> 
> I am not sure if anyone know what really happens here. I suggest to
> enable lockdep. It might detect possible deadlock even before it
> really happens, see Documentation/locking/lockdep-design.txt
> 
> It can be enabled by
> 
>    CONFIG_PROVE_LOCKING=y
> 
> It depends on
> 
>     CONFIG_DEBUG_KERNEL=y
> 
> and maybe some more options, see lib/Kconfig.debug

Thanks a lot! I caught this stack dump:

starting version 230
[    3.416647] ------------[ cut here ]------------
[    3.417310] WARNING: CPU: 0 PID: 95 at
/home/topi/d/linux.git/kernel/locking/lockdep.c:2871
lockdep_trace_alloc+0xb4/0xc0
[    3.417605] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
[    3.417923] Modules linked in:
[    3.418288] CPU: 0 PID: 95 Comm: systemd-udevd Not tainted 4.7.0-rc5+ #97
[    3.418444] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS Debian-1.8.2-1 04/01/2014
[    3.418726]  0000000000000086 000000007970f3b0 ffff88000016fb00
ffffffff813c9c45
[    3.418993]  ffff88000016fb50 0000000000000000 ffff88000016fb40
ffffffff81091e9b
[    3.419176]  00000b3705e2c798 0000000000000046 0000000000000410
00000000ffffffff
[    3.419374] Call Trace:
[    3.419511]  [<ffffffff813c9c45>] dump_stack+0x67/0x92
[    3.419644]  [<ffffffff81091e9b>] __warn+0xcb/0xf0
[    3.419745]  [<ffffffff81091f1f>] warn_slowpath_fmt+0x5f/0x80
[    3.419868]  [<ffffffff810e9a84>] lockdep_trace_alloc+0xb4/0xc0
[    3.419988]  [<ffffffff8120dc42>] kmem_cache_alloc_node+0x42/0x600
[    3.420156]  [<ffffffff8110432d>] ? debug_lockdep_rcu_enabled+0x1d/0x20
[    3.420170]  [<ffffffff8163183b>] __alloc_skb+0x5b/0x1d0
[    3.420170]  [<ffffffff81144f6b>] audit_log_start+0x29b/0x480
[    3.420170]  [<ffffffff810a2925>] ? __lock_task_sighand+0x95/0x270
[    3.420170]  [<ffffffff81145cc9>] audit_log_cap_use+0x39/0xf0
[    3.420170]  [<ffffffff8109cd75>] ns_capable+0x45/0x70
[    3.420170]  [<ffffffff8109cdb7>] capable+0x17/0x20
[    3.420170]  [<ffffffff812a2f50>] oom_score_adj_write+0x150/0x2f0
[    3.420170]  [<ffffffff81230997>] __vfs_write+0x37/0x160
[    3.420170]  [<ffffffff810e33b7>] ? update_fast_ctr+0x17/0x30
[    3.420170]  [<ffffffff810e3449>] ? percpu_down_read+0x49/0x90
[    3.420170]  [<ffffffff81233d47>] ? __sb_start_write+0xb7/0xf0
[    3.420170]  [<ffffffff81233d47>] ? __sb_start_write+0xb7/0xf0
[    3.420170]  [<ffffffff81231048>] vfs_write+0xb8/0x1b0
[    3.420170]  [<ffffffff812533c6>] ? __fget_light+0x66/0x90
[    3.420170]  [<ffffffff81232078>] SyS_write+0x58/0xc0
[    3.420170]  [<ffffffff81001f2c>] do_syscall_64+0x5c/0x300
[    3.420170]  [<ffffffff81849c9a>] entry_SYSCALL64_slow_path+0x25/0x25
[    3.420170] ---[ end trace fb586899fb556a5e ]---
[    3.447922] random: systemd-udevd urandom read with 3 bits of entropy
available
[    4.014078] clocksource: Switched to clocksource tsc
Begin: Loading essential drivers ... done.

This is with qemu and the boot continues normally. With real computer,
there's no such output and system just seems to freeze.

Could it be possible that the deadlock happens because there's some IO
towards /sys/fs/cgroup, which causes a capability check and that in turn
causes locking problems when we try to print cgroup list?

-Topi

[toc] | [prev] | [next] | [standalone]

#1439202

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
> >> message, but unfortunately the call to audit_cgroup_list() deadlocks the
> >> system when booting a full blown OS. There's no deadlock when the call
> >> is removed.
> >>
> >> I guess that in some cases, cgroup_mutex and/or css_set_lock could be
> >> already held earlier before entering audit_cgroup_list(). Holding the
> >> locks is however required by task_cgroup_from_root(). Is there any way
> >> to avoid this? For example, only print some kind of cgroup ID numbers
> >> (are there unique and stable IDs, available without locks?) for those
> >> cgroups where the task is registered in the audit message?
> > 
> > I am not sure if anyone know what really happens here. I suggest to
> > enable lockdep. It might detect possible deadlock even before it
> > really happens, see Documentation/locking/lockdep-design.txt
> > 
> > It can be enabled by
> > 
> >    CONFIG_PROVE_LOCKING=y
> > 
> > It depends on
> > 
> >     CONFIG_DEBUG_KERNEL=y
> > 
> > and maybe some more options, see lib/Kconfig.debug
> 
> Thanks a lot! I caught this stack dump:
> 
> starting version 230
> [    3.416647] ------------[ cut here ]------------
> [    3.417310] WARNING: CPU: 0 PID: 95 at
> /home/topi/d/linux.git/kernel/locking/lockdep.c:2871
> lockdep_trace_alloc+0xb4/0xc0
> [    3.417605] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
> [    3.417923] Modules linked in:
> [    3.418288] CPU: 0 PID: 95 Comm: systemd-udevd Not tainted 4.7.0-rc5+ #97
> [    3.418444] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS Debian-1.8.2-1 04/01/2014
> [    3.418726]  0000000000000086 000000007970f3b0 ffff88000016fb00
> ffffffff813c9c45
> [    3.418993]  ffff88000016fb50 0000000000000000 ffff88000016fb40
> ffffffff81091e9b
> [    3.419176]  00000b3705e2c798 0000000000000046 0000000000000410
> 00000000ffffffff
> [    3.419374] Call Trace:
> [    3.419511]  [<ffffffff813c9c45>] dump_stack+0x67/0x92
> [    3.419644]  [<ffffffff81091e9b>] __warn+0xcb/0xf0
> [    3.419745]  [<ffffffff81091f1f>] warn_slowpath_fmt+0x5f/0x80
> [    3.419868]  [<ffffffff810e9a84>] lockdep_trace_alloc+0xb4/0xc0
> [    3.419988]  [<ffffffff8120dc42>] kmem_cache_alloc_node+0x42/0x600
> [    3.420156]  [<ffffffff8110432d>] ? debug_lockdep_rcu_enabled+0x1d/0x20
> [    3.420170]  [<ffffffff8163183b>] __alloc_skb+0x5b/0x1d0
> [    3.420170]  [<ffffffff81144f6b>] audit_log_start+0x29b/0x480
> [    3.420170]  [<ffffffff810a2925>] ? __lock_task_sighand+0x95/0x270
> [    3.420170]  [<ffffffff81145cc9>] audit_log_cap_use+0x39/0xf0
> [    3.420170]  [<ffffffff8109cd75>] ns_capable+0x45/0x70
> [    3.420170]  [<ffffffff8109cdb7>] capable+0x17/0x20
> [    3.420170]  [<ffffffff812a2f50>] oom_score_adj_write+0x150/0x2f0
> [    3.420170]  [<ffffffff81230997>] __vfs_write+0x37/0x160
> [    3.420170]  [<ffffffff810e33b7>] ? update_fast_ctr+0x17/0x30
> [    3.420170]  [<ffffffff810e3449>] ? percpu_down_read+0x49/0x90
> [    3.420170]  [<ffffffff81233d47>] ? __sb_start_write+0xb7/0xf0
> [    3.420170]  [<ffffffff81233d47>] ? __sb_start_write+0xb7/0xf0
> [    3.420170]  [<ffffffff81231048>] vfs_write+0xb8/0x1b0
> [    3.420170]  [<ffffffff812533c6>] ? __fget_light+0x66/0x90
> [    3.420170]  [<ffffffff81232078>] SyS_write+0x58/0xc0
> [    3.420170]  [<ffffffff81001f2c>] do_syscall_64+0x5c/0x300
> [    3.420170]  [<ffffffff81849c9a>] entry_SYSCALL64_slow_path+0x25/0x25
> [    3.420170] ---[ end trace fb586899fb556a5e ]---
> [    3.447922] random: systemd-udevd urandom read with 3 bits of entropy
> available
> [    4.014078] clocksource: Switched to clocksource tsc
> Begin: Loading essential drivers ... done.
> 
> This is with qemu and the boot continues normally. With real computer,
> there's no such output and system just seems to freeze.
> 
> Could it be possible that the deadlock happens because there's some IO
> towards /sys/fs/cgroup, which causes a capability check and that in turn
> causes locking problems when we try to print cgroup list?

The above warning is printed by the code from
kernel/locking/lockdep.c:2871

static void __lockdep_trace_alloc(gfp_t gfp_mask, unsigned long flags)
{
[...]
	/* We're only interested __GFP_FS allocations for now */
	if (!(gfp_mask & __GFP_FS))
		return;

	/*
	 * Oi! Can't be having __GFP_FS allocations with IRQs disabled.
	 */
	if (DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)))
		return;


The backtrace shows that your new audit_log_cap_use() is called
from vfs_write(). You might try to use audit_log_start() with
GFP_NOFS instead of GFP_KERNEL.

Note that this is rather intuitive advice. I still need to learn a lot
about memory management and kernel in general to be more sure about
a correct solution.

Best Regards,
Petr

[toc] | [prev] | [next] | [standalone]

#1439960

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 tests as you can see from the commit
>>>> message, but unfortunately the call to audit_cgroup_list() deadlocks the
>>>> system when booting a full blown OS. There's no deadlock when the call
>>>> is removed.
>>>>
>>>> I guess that in some cases, cgroup_mutex and/or css_set_lock could be
>>>> already held earlier before entering audit_cgroup_list(). Holding the
>>>> locks is however required by task_cgroup_from_root(). Is there any way
>>>> to avoid this? For example, only print some kind of cgroup ID numbers
>>>> (are there unique and stable IDs, available without locks?) for those
>>>> cgroups where the task is registered in the audit message?
>>>
>>> I am not sure if anyone know what really happens here. I suggest to
>>> enable lockdep. It might detect possible deadlock even before it
>>> really happens, see Documentation/locking/lockdep-design.txt
>>>
>>> It can be enabled by
>>>
>>>    CONFIG_PROVE_LOCKING=y
>>>
>>> It depends on
>>>
>>>     CONFIG_DEBUG_KERNEL=y
>>>
>>> and maybe some more options, see lib/Kconfig.debug
>>
>> Thanks a lot! I caught this stack dump:
>>
>> starting version 230
>> [    3.416647] ------------[ cut here ]------------
>> [    3.417310] WARNING: CPU: 0 PID: 95 at
>> /home/topi/d/linux.git/kernel/locking/lockdep.c:2871
>> lockdep_trace_alloc+0xb4/0xc0
>> [    3.417605] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
>> [    3.417923] Modules linked in:
>> [    3.418288] CPU: 0 PID: 95 Comm: systemd-udevd Not tainted 4.7.0-rc5+ #97
>> [    3.418444] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
>> BIOS Debian-1.8.2-1 04/01/2014
>> [    3.418726]  0000000000000086 000000007970f3b0 ffff88000016fb00
>> ffffffff813c9c45
>> [    3.418993]  ffff88000016fb50 0000000000000000 ffff88000016fb40
>> ffffffff81091e9b
>> [    3.419176]  00000b3705e2c798 0000000000000046 0000000000000410
>> 00000000ffffffff
>> [    3.419374] Call Trace:
>> [    3.419511]  [<ffffffff813c9c45>] dump_stack+0x67/0x92
>> [    3.419644]  [<ffffffff81091e9b>] __warn+0xcb/0xf0
>> [    3.419745]  [<ffffffff81091f1f>] warn_slowpath_fmt+0x5f/0x80
>> [    3.419868]  [<ffffffff810e9a84>] lockdep_trace_alloc+0xb4/0xc0
>> [    3.419988]  [<ffffffff8120dc42>] kmem_cache_alloc_node+0x42/0x600
>> [    3.420156]  [<ffffffff8110432d>] ? debug_lockdep_rcu_enabled+0x1d/0x20
>> [    3.420170]  [<ffffffff8163183b>] __alloc_skb+0x5b/0x1d0
>> [    3.420170]  [<ffffffff81144f6b>] audit_log_start+0x29b/0x480
>> [    3.420170]  [<ffffffff810a2925>] ? __lock_task_sighand+0x95/0x270
>> [    3.420170]  [<ffffffff81145cc9>] audit_log_cap_use+0x39/0xf0
>> [    3.420170]  [<ffffffff8109cd75>] ns_capable+0x45/0x70
>> [    3.420170]  [<ffffffff8109cdb7>] capable+0x17/0x20
>> [    3.420170]  [<ffffffff812a2f50>] oom_score_adj_write+0x150/0x2f0
>> [    3.420170]  [<ffffffff81230997>] __vfs_write+0x37/0x160
>> [    3.420170]  [<ffffffff810e33b7>] ? update_fast_ctr+0x17/0x30
>> [    3.420170]  [<ffffffff810e3449>] ? percpu_down_read+0x49/0x90
>> [    3.420170]  [<ffffffff81233d47>] ? __sb_start_write+0xb7/0xf0
>> [    3.420170]  [<ffffffff81233d47>] ? __sb_start_write+0xb7/0xf0
>> [    3.420170]  [<ffffffff81231048>] vfs_write+0xb8/0x1b0
>> [    3.420170]  [<ffffffff812533c6>] ? __fget_light+0x66/0x90
>> [    3.420170]  [<ffffffff81232078>] SyS_write+0x58/0xc0
>> [    3.420170]  [<ffffffff81001f2c>] do_syscall_64+0x5c/0x300
>> [    3.420170]  [<ffffffff81849c9a>] entry_SYSCALL64_slow_path+0x25/0x25
>> [    3.420170] ---[ end trace fb586899fb556a5e ]---
>> [    3.447922] random: systemd-udevd urandom read with 3 bits of entropy
>> available
>> [    4.014078] clocksource: Switched to clocksource tsc
>> Begin: Loading essential drivers ... done.
>>
>> This is with qemu and the boot continues normally. With real computer,
>> there's no such output and system just seems to freeze.
>>
>> Could it be possible that the deadlock happens because there's some IO
>> towards /sys/fs/cgroup, which causes a capability check and that in turn
>> causes locking problems when we try to print cgroup list?
> 
> The above warning is printed by the code from
> kernel/locking/lockdep.c:2871
> 
> static void __lockdep_trace_alloc(gfp_t gfp_mask, unsigned long flags)
> {
> [...]
> 	/* We're only interested __GFP_FS allocations for now */
> 	if (!(gfp_mask & __GFP_FS))
> 		return;
> 
> 	/*
> 	 * Oi! Can't be having __GFP_FS allocations with IRQs disabled.
> 	 */
> 	if (DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)))
> 		return;
> 
> 
> The backtrace shows that your new audit_log_cap_use() is called
> from vfs_write(). You might try to use audit_log_start() with
> GFP_NOFS instead of GFP_KERNEL.
> 
> Note that this is rather intuitive advice. I still need to learn a lot
> about memory management and kernel in general to be more sure about
> a correct solution.

Here's what I got now:

[   18.043181]
[   18.044123] ======================================================
[   18.044123] [ INFO: possible circular locking dependency detected ]
[   18.044123] 4.7.0-rc5+ #99 Not tainted
[   18.044123] -------------------------------------------------------
[   18.044123] systemd/1 is trying to acquire lock:
[   18.044123]  (tasklist_lock){.+.+..}, at: [<ffffffff81137ae1>]
cgroup_mount+0x4f1/0xc10
[   18.044123]
[   18.044123] but task is already holding lock:
[   18.044123]  (css_set_lock){......}, at: [<ffffffff81137a9d>]
cgroup_mount+0x4ad/0xc10
[   18.044123]
[   18.044123] which lock already depends on the new lock.
[   18.044123]
[   18.044123]
[   18.044123] the existing dependency chain (in reverse order) is:
[   18.044123]
-> #3 (css_set_lock){......}:
[   18.044123]        [<ffffffff810e92b3>] lock_acquire+0xe3/0x1c0
[   18.044123]        [<ffffffff8184e187>] _raw_spin_lock_irq+0x37/0x50
[   18.044123]        [<ffffffff811374be>] cgroup_setup_root+0x19e/0x2d0
[   18.044123]        [<ffffffff821911fc>] cgroup_init+0xec/0x41d
[   18.044123]        [<ffffffff82171f68>] start_kernel+0x40c/0x465
[   18.044123]        [<ffffffff82171294>]
x86_64_start_reservations+0x2f/0x31
[   18.044123]        [<ffffffff8217140e>] x86_64_start_kernel+0x178/0x18b
[   18.044123]
-> #2 (cgroup_mutex){+.+...}:
[   18.044123]        [<ffffffff810e92b3>] lock_acquire+0xe3/0x1c0
[   18.044123]        [<ffffffff8184afaf>] mutex_lock_nested+0x5f/0x350
[   18.044123]        [<ffffffff8113967a>] audit_cgroup_list+0x4a/0x2f0
[   18.044123]        [<ffffffff81145d69>] audit_log_cap_use+0xd9/0xf0
[   18.044123]        [<ffffffff8109cd75>] ns_capable+0x45/0x70
[   18.044123]        [<ffffffff8109cdb7>] capable+0x17/0x20
[   18.044123]        [<ffffffff812a2f50>] oom_score_adj_write+0x150/0x2f0
[   18.044123]        [<ffffffff81230997>] __vfs_write+0x37/0x160
[   18.044123]        [<ffffffff81231048>] vfs_write+0xb8/0x1b0
[   18.044123]        [<ffffffff81232078>] SyS_write+0x58/0xc0
[   18.044123]        [<ffffffff81001f2c>] do_syscall_64+0x5c/0x300
[   18.044123]        [<ffffffff8184ea5a>] return_from_SYSCALL_64+0x0/0x7a
[   18.044123]
-> #1 (&(&sighand->siglock)->rlock){+.+...}:
[   18.044123]        [<ffffffff810e92b3>] lock_acquire+0xe3/0x1c0
[   18.044123]        [<ffffffff8184e011>] _raw_spin_lock+0x31/0x40
[   18.044123]        [<ffffffff810901d9>]
copy_process.part.34+0x10f9/0x1b40
[   18.044123]        [<ffffffff81090e23>] _do_fork+0xf3/0x6b0
[   18.044123]        [<ffffffff81091409>] kernel_thread+0x29/0x30
[   18.044123]        [<ffffffff810b71d7>] kthreadd+0x187/0x1e0
[   18.044123]        [<ffffffff8184ebbf>] ret_from_fork+0x1f/0x40
[   18.044123]
-> #0 (tasklist_lock){.+.+..}:
[   18.044123]        [<ffffffff810e8dfb>] __lock_acquire+0x13cb/0x1440
[   18.044123]        [<ffffffff810e92b3>] lock_acquire+0xe3/0x1c0
[   18.044123]        [<ffffffff8184e444>] _raw_read_lock+0x34/0x50
[   18.044123]        [<ffffffff81137ae1>] cgroup_mount+0x4f1/0xc10
[   18.044123]        [<ffffffff81234de8>] mount_fs+0x38/0x170
[   18.044123]        [<ffffffff812562bb>] vfs_kern_mount+0x6b/0x150
[   18.044123]        [<ffffffff81258fdc>] do_mount+0x24c/0xe30
[   18.044123]        [<ffffffff81259ef5>] SyS_mount+0x95/0xe0
[   18.044123]        [<ffffffff8184e9a5>]
entry_SYSCALL_64_fastpath+0x18/0xa8
[   18.044123]
[   18.044123] other info that might help us debug this:
[   18.044123]
[   18.044123] Chain exists of:
  tasklist_lock --> cgroup_mutex --> css_set_lock

[   18.044123]  Possible unsafe locking scenario:
[   18.044123]
[   18.044123]        CPU0                    CPU1
[   18.044123]        ----                    ----
[   18.044123]   lock(css_set_lock);
[   18.044123]                                lock(cgroup_mutex);
[   18.044123]                                lock(css_set_lock);
[   18.044123]   lock(tasklist_lock);
[   18.044123]
[   18.044123]  *** DEADLOCK ***
[   18.044123]
[   18.044123] 1 lock held by systemd/1:
[   18.044123]  #0:  (css_set_lock){......}, at: [<ffffffff81137a9d>]
cgroup_mount+0x4ad/0xc10
[   18.044123]
[   18.044123] stack backtrace:
[   18.044123] CPU: 0 PID: 1 Comm: systemd Not tainted 4.7.0-rc5+ #99
[   18.044123] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS Debian-1.8.2-1 04/01/2014
[   18.044123]  0000000000000086 0000000008966b11 ffff880006d13bb0
ffffffff813c9c45
[   18.044123]  ffffffff829dbed0 ffffffff829cf2a0 ffff880006d13bf0
ffffffff810e60a3
[   18.044123]  ffff880006d13c30 ffff880006d067b0 ffff880006d06040
0000000000000001
[   18.044123] Call Trace:
[   18.044123]  [<ffffffff813c9c45>] dump_stack+0x67/0x92
[   18.044123]  [<ffffffff810e60a3>] print_circular_bug+0x1e3/0x250
[   18.044123]  [<ffffffff810e8dfb>] __lock_acquire+0x13cb/0x1440
[   18.044123]  [<ffffffff810e92b3>] lock_acquire+0xe3/0x1c0
[   18.044123]  [<ffffffff81137ae1>] ? cgroup_mount+0x4f1/0xc10
[   18.044123]  [<ffffffff8184e444>] _raw_read_lock+0x34/0x50
[   18.044123]  [<ffffffff81137ae1>] ? cgroup_mount+0x4f1/0xc10
[   18.044123]  [<ffffffff81137ae1>] cgroup_mount+0x4f1/0xc10
[   18.044123]  [<ffffffff810e5637>] ? lockdep_init_map+0x57/0x1f0
[   18.044123]  [<ffffffff81234de8>] mount_fs+0x38/0x170
[   18.044123]  [<ffffffff812562bb>] vfs_kern_mount+0x6b/0x150
[   18.044123]  [<ffffffff81258fdc>] do_mount+0x24c/0xe30
[   18.044123]  [<ffffffff8121060b>] ? kmem_cache_alloc_trace+0x28b/0x5e0
[   18.044123]  [<ffffffff811cc1c6>] ? strndup_user+0x46/0x80
[   18.044123]  [<ffffffff81259ef5>] SyS_mount+0x95/0xe0
[   18.044123]  [<ffffffff8184e9a5>] entry_SYSCALL_64_fastpath+0x18/0xa8

This is with GFP_KERNEL changed to GFP_NOFS for both allocations.

-Topi

[toc] | [prev] | [next] | [standalone]

#1432234

On 06/27/16 14:54, Serge E. Hallyn wrote:
> Quoting Tejun Heo (tj@kernel.org):
>> Hello, Topi.
>>
>> On Sun, Jun 26, 2016 at 3:14 PM, Topi Miettinen <toiwoton@gmail.com> 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 do it)
>>> and it collects the exit status without collecting other info, can you
>>> suggest a different way how another process could collect it 100% reliably?
>>
>> I'm not saying that there's such mechanism now. I'm suggesting that
>> that'd be a more fitting way of implementing a new mechanism to track
>> capability usages.
> 
> Hi Topi,
> 
> I think Eric was right a few emails earlier that the audit subsystem is
> really the most appropriate answer to this.  (Perhaps sysctl-controllered?)
> Combined with taskstats it would give you what you need.  Or you could even
> use an empty new named cgroup controller, say 'none,name=caps', and then
> look only at audit results for cgroup '/myapp' in the caps hierarchy.
> 

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, right?
With cgroup (or /proc), no new tools would be needed.

-Topi

[toc] | [prev] | [next] | [standalone]

#1430832

"Serge E. Hallyn" <serge@hallyn.com> writes:

> Quoting Tejun Heo (tj@kernel.org):
>> Hello,
>> 
>> On Fri, Jun 24, 2016 at 10:59:16AM -0500, Serge E. Hallyn wrote:
>> > Quoting Tejun Heo (tj@kernel.org):
>> > > But isn't being recursive orthogonal to using cgroup?  Why not account
>> > > usages recursively along the process hierarchy?  Capabilities don't
>> > > have much to do with cgroup but everything with process hierarchy.
>> > > That's how they're distributed and modified.  If monitoring their
>> > > usages is necessary, it makes sense to do it in the same structure.
>> > 
>> > That was my argument against using cgroups to enforce a new bounding
>> > set.  For tracking though, the cgroup process tracking seems as applicable
>> > to this as it does to systemd tracking of services.  It tracks a task and
>> > the children it forks.
>> 
>> 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
>> is implemented anyway?
>
> As I think Topi pointed out, one shortcoming is that if there is a short-lived
> child task, using its /proc/self/status is racy.  You might just miss that it
> ever even existed, let alone that the "application" needed it.
>
> Another alternative we've both mentioned is to use systemtap.  That's not
> as nice a solution as a cgroup, but then again this isn't really a common
> case, so maybe it is precisely what a tracing infrastructure is meant for.

Hmm.

We have capability use wired up into auditing.  So we might be able to
get away with just adding an appropriate audit message in
commoncap.c:cap_capable that honors the audit flag and logs an audit
message.  The hook in selinux already appears to do that.

Certainly audit sounds like the subsystem for this kind of work, as it's
whole point in life is logging things, then something in userspace can
just run over the audit longs and build a nice summary.

Eric

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web