Merge lp://staging/~smcv/apparmor/cpus-conf into lp://staging/apparmor/2.12
| Status: | Merged |
|---|---|
| Merged at revision: | 3654 |
| Proposed branch: | lp://staging/~smcv/apparmor/cpus-conf |
| Merge into: | lp://staging/apparmor/2.12 |
| Diff against target: |
11 lines (+1/-0) 1 file modified
profiles/apparmor.d/abstractions/base (+1/-0) |
| To merge this branch: | bzr merge lp://staging/~smcv/apparmor/cpus-conf |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Steve Beattie | Approve | ||
|
Review via email:
|
|||
Description of the change
abstractions/base: Allow sysconf(
glibc implements this by doing a readdir() and filtering.
We already allowed sysconf(
basically a read from /sys/devices/
---
For context: while testing a confined process that invokes apparmor_parser under its own profile, I noticed that apparmor_parser does this. For now I'm adding it to that process's profile, but it seems like something that could reasonably go in <abstractions/base> - in practice on consumer systems the answer is going to be the same as cpu/online, which we already allow reading.
(I realise that's an odd thing to do, because that confined process needs to exercise CAP_MAC_ADMIN, making it all-powerful. However, the confinement is aiming to prevent accidentally reading untrusted content into a TCB process, rather than preventing the process itself from escalating privileges.)
Yes, that sounds reasonable. Certainly other tools might try to scale workload according to available processors.
Merged to trunk and the 2.11 branch, thanks!