On 06/23/16 23:46, Andrew Morton wrote: > On Thu, 23 Jun 2016 18:07:10 +0300 Topi Miettinen <toiwoton@xxxxxxxxx> 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. > > I'm having trouble understanding how valuable this feature is to our > users, and that's a rather important thing! > > Perhaps it would help if you were to explain your motivation: > particular use cases which benefited from this, for example. > It's easy to control with for example systemd or many other tools, which capabilities a service should have at the start. But how should a system administrator, application developer or distro maintaner ever determine a suitable value for this? Currently the only way seems to be to become an expert on capabilities, make an educated guess how the set of programs in question happen to work in this context and especially how they could exercise the capabilites in all possible use cases. Even then, the outcome is to just try something to see if that happens to work. Reading the source code (if available) does not help very much, because the use of capabilities is anything but explicit there. This is way too difficult, there must be some easier way. The information which capabilities actually were used in a trial run gives a much better starting point. The users can just use the list of used capabilities with configuring the service or when developing or maintaining the application. Of course, even that could still fail eventually, but then you simply copy the new value of used capabilities to the configuration, whereas currently you have to reconsider your understanding of the capabilities and the programs in light of the failure, which by itself might give no new useful information. One way to solve this for good would be to make the use of capabilities explicit in the ABI. For example, there could be a system call dac_override() which would be the only possible way ever to use the capability CAP_DAC_OVERRIDE and so forth. Then reading source code, tracing and many other approaches would be useful. But the OS with that kind of ABI (not Linux) would not be Unix-like at all for any (potentially) capability using programs, like find(1) or cat(1). -Topi -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
