[0/4] Honor cgroup namespace when resolving cgroup id

Message

Michal Koutný Aug. 26, 2022, 4:52 p.m. UTC

Cgroup id is becoming a new way for userspace how to refer to cgroups it
wants to act upon. As opposed to cgroupfs (paths, opened FDs), the
current approach does not reflect limited view by (non-init) cgroup
namespaces.

This patches don't aim to limit what a user can do (consider an uid=0 in
mere cgroup namespace) but to provide consistent view within a
namespace.

The series is based on bpf-next with the new cgroup_iter. I've only
boot-tested it (especially I didn't run the BPF selftest).

Michal Koutný (4):
  cgroup: Honor caller's cgroup NS when resolving path
  cgroup: cgroup: Honor caller's cgroup NS when resolving cgroup id
  cgroup: Homogenize cgroup_get_from_id() return value
  cgroup/bpf: Honor cgroup NS in cgroup_iter for ancestors

 block/blk-cgroup-fc-appid.c |  4 +--
 include/linux/cgroup.h      |  8 +++---
 kernel/bpf/cgroup_iter.c    |  9 ++++---
 kernel/cgroup/cgroup.c      | 53 ++++++++++++++++++++++++++++---------
 mm/memcontrol.c             |  4 +--
 5 files changed, 54 insertions(+), 24 deletions(-)


base-commit: 343949e10798a52c6d6a14effc962e010ed471ae

Comments

Tejun Heo Aug. 26, 2022, 8:59 p.m. UTC | #1

On Fri, Aug 26, 2022 at 06:52:34PM +0200, Michal Koutný wrote:
> Cgroup id is becoming a new way for userspace how to refer to cgroups it
> wants to act upon. As opposed to cgroupfs (paths, opened FDs), the
> current approach does not reflect limited view by (non-init) cgroup
> namespaces.
> 
> This patches don't aim to limit what a user can do (consider an uid=0 in
> mere cgroup namespace) but to provide consistent view within a
> namespace.

Applied 1-3 to cgroup/for-6.1. The branch will be stable, so please feel
free to pull from bpf/for-next.

Thanks.

Tejun Heo Aug. 26, 2022, 9:08 p.m. UTC | #2

Hello,

On Fri, Aug 26, 2022 at 06:52:34PM +0200, Michal Koutný wrote:
> Cgroup id is becoming a new way for userspace how to refer to cgroups it
> wants to act upon. As opposed to cgroupfs (paths, opened FDs), the
> current approach does not reflect limited view by (non-init) cgroup
> namespaces.

Looking at the code, I'm not quite sure we're actually plugging all holes in
terms of lookup. I think cgroup_get_from_path() would allow walking up past
the ns boundary. We aren't using kernfs ns support and I don't see anything
preventing ..'ing past the boundary.

> This patches don't aim to limit what a user can do (consider an uid=0 in
> mere cgroup namespace) but to provide consistent view within a
> namespace.

Considering userns and the fact that we try to isolate two separate sub
hierarchies delegated to the same UID, I think we'd have to tighten down on
the behaviors so that visiblity scope matches the permission scope.

Thanks.