Messages in this thread | | | Date | Mon, 4 Jun 2007 04:56:48 -0700 | From | Stephane Eranian <> | Subject | Re: [PATCH 13/22] 2.6.22-rc3 perfmon2 : common core functions |
| |
Andi,
On Thu, May 31, 2007 at 05:01:38PM +0200, Andi Kleen wrote: > > + * pmu_desc: subdir containing the PMU register mapping information > > + > > + * reset_stats(W): echo 0 > reset_stats resets the statistics collected by perfmon2. > > + stats are available per-cpu in /sys/devices/system/cpu/cpu*/perfmon > > + > > + * smpl_buffer_mem_cur(RO): reports the amount of memory currently dedicated to sampling > > + buffers by the kernel. > > + > > + * smpl_buffer_mem_max(RW): maximum amount of memory usable for sampling buffers. > > + -1 means all that is available. > > -1 seems dangerous. > > > + > > + * sys_group(RW): which users group is allowed to create a system-wide contexts. > > + -1 means any group > > Wouldn't this better be a capability bit? Then it could be just set > in the normal pam configuration files. > > > + > > + * sys_sessions_count(RO): number of loaded system-wide contexts > > + > > + * task_group(RW): which users group is allowed to create per-thread contexts. > > + -1 means any group >
I spent quite some time looking at the kernel code for capabilities and also how to control them from userland. I agree with you that it would be nicer to use capabilities to control which users can create system-wide or per-thread perfmon sessions. We could simply create two new capabilities: CAP_PERFMON_SYS and CAP_PERFMON_THREAD. Then, I can envision a setup where a sysadmin would grant the capabilities to users when they login via PAM.
There are two problems with this at the moment:
- the 32bit for capabilities have been exhausted (kernel_cap_t is u32). We would need to increase to u64. That would impact __user_cap_data_struct which is used by the captset()/capget() syscalls.
- I have not been able to find how one could grant/deny capabilities via PAM and especially for login. Libcap does not seem to be used. There was a pam_cap at some point, it seems abandonned by now. I am not a linux security expert, so there may be newer ways of setting capabilities for processes.
Any comments?
-- -Stephane - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |