Unity8 needs to have CAP_SYS_RESOURCE set to be able to adjust oom[_score]_adj for lifecycle mgmt

I have given approval for the Unity 8 binary to gain CAP_SYS_RESOURCE via fscaps. It can be set using setcap in the package postinst.

I don't believe there are any escalation issues with CAP_SYS_RESOURCE, and it makes sense for Unity 8 to manage application lifecycle.

That being said, if we do discover that giving Unity 8 CAP_SYS_RESOURCE is problematic in the future, we can simply move the oom_score_adj code to it's own small helper daemon without too much work.

I don't like this proposed change.

Unity8 could, with CAP_SYS_RESOURCE:

- Allocate more-than-expected IPC resources
- Modify the rlimits of any process on the system
- Ignore its own rlimits
- Use the "reserve" 5% filesystem capacity held aside for root
- Set the refresh rate of the real time clock and high-resolution timers to high values, draining battery and potentially dragging performance
- Change ext3 / ext4 / ocfs2 JOURNAL_DATA flag
- Extend ext3 / ext4 / ocfs2 filesystems
- Use CONFIG_FAULT_INJECTION tools
- Issue UBI volume update command
- Create, remove, rename, and resize UBI volumes
- Attach and detach UBI MTD devices

(I've removed the ones that require a second capability if I could determine quickly that a second capability was necessary.)

Inspecting the oom_score_adj_write() code in my copy of the kernel sources gives me the impression that Unity8 could manipulate the oom_score_adj within fairly large margins even without this capability. (See e.g. http://fxr.watson.org/fxr/source/fs/proc/base.c?v=linux-2.6#L996 )

I would expect that the range allowed is sufficient for Unity8 to "strongly recommend" which of the User's launched tasks should and which should not be killed.

Has this range been tested and found to be insufficient?

Since an application can spawn many hundreds of processes without any real effort, I fear that even oom_score_adj controls to suggest which "application" to kill might not be accurate enough for us -- one "application", as the user knows it, might spawn hundreds of processes that individually are small enough to be passed over by the oom-killer. In the long run we may wish to investigate use of the cgroups OOM management facilities -- I don't believe that cgroups would let us select which process to kill, but processes attempting to make memory allocations beyond limits could be put to sleep, which would be a step in the right direction. See e.g. https://www.kernel.org/doc/Documentation/cgroups/memory.txt (Section 10 in particular) for more information.

Thanks

According to http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-saucy.git;a=blob;f=fs/proc/base.c#l978, lowering the oom_score_adj of a task always requires CAP_SYS_RESOURCE. We are adjusting these values from the shell accounting for visibility and focus of applications. The respective oom scores are then picked up the by the android low-memory killer that selects processes to be killed depending on their oom-score and w.r.t. to "banding" the range of potential oom scores and interpreting them as "App in foreground", "App in background" etc.. That is, while cgroups are quite interesting to limit resource usage of rogue application, the approach we are choosing is tailored towards our lifecycle model.

it would be interesting to give oom_score_adj powers to upstart. At the moment system level jobs can have oom score declared in the job.conf files, but as far as i know no way to dynamically adjust them. And then no such capability is exposed to session level init. If exposed via upstart, it would then be accesible via dbus api to just do that. (and we have sufficient policykit / dbus mediation to export that functionality over dbus & grant unity8 to control it?!)

Just to be clear with regards to my comment #1:

Setting CAP_SYS_RESOURCE via fscaps should only be a temporary measure since we're late in the cycle and Unity 8 is only used for Touch for the moment. The ultimate goal should be to come up with a privileged helper daemon that unity 8 can communicate with to adjust running application's oom score. The daemon can enforce security restrictions, including making sure the requesting Unity is for the currently active user, etc.

@Marc: Would it then make sense to consider Dmitrijs proposal? Or would we need a system-level component, e.g., the system-level shell to expose the required functionality via dbus?

Doing it with upstart means it would need to be the system upstart that would modify the actual oom score, or else you'll need to grant CAP_SYS_RESOURCE to the session upstart, which is basically the equivalent of granting it to the user it's running under.

Using the system upstart or the system-level shell both sound like interesting ideas.

This bug was fixed in the package unity-mir - 0.1+13.10.20131016-0ubuntu1

---------------
unity-mir (0.1+13.10.20131016-0ubuntu1) saucy; urgency=low

  [ thomas-voss ]
  * Slightly refactor the OOM adjustments to be a pure implementation
    detail of the TaskManager. (LP: #1238691)

  [ Ricardo Mendoza ]
  * Slightly refactor the OOM adjustments to be a pure implementation
    detail of the TaskManager. (LP: #1238691)

  [ Ubuntu daily release ]
  * Automatic snapshot from revision 127
 -- Ubuntu daily release <email address hidden> Wed, 16 Oct 2013 11:01:55 +0000