Re: [RFC] cells: a container as one kernel object

[Andrew Halaney <andrew@amutable.com>]

On Mon, Oct 19, 2026 at 04:50:47PM +0000, Josef Bacik wrote:

(...)

> The system calls
> ================
> 
> They are split by what they do, as the mount API is, so that "may look but not touch"
> is a system call number: ``cell_info()`` changes nothing.
> 
> .. code-block:: c
> 
>    int cell_create(int parent, unsigned int flags);
>    int cell_configure(int cfd, unsigned int cmd, const char *key,
>                       const void *value, int aux);
>    int cell_info(int cfd, struct cell_info *info, size_t size,
>                  unsigned int flags);
>    int cell_open(int cfd, unsigned int what, const char *key, const void *arg,
>                  unsigned int flags);
>    int task_configure(int pidfd, unsigned int cmd, const char *key,
>                       const void *value, int aux);
> 
> ``cell_create()``
>   makes a new, empty cell and returns a cellfd, which is always close-on-exec.
>   ``parent`` is ``CELL_SELF``.  It takes no privilege, but it makes a user namespace,
>   and what applies to those applies here: ``user.max_user_namespaces``, the LSM hook,
>   and no chrooted caller.

One thing to consider here is how we want ucounts to be handled. I've
been burned by those in the past, since if your container builder runs
as root the ucount accounting rolls up the counts to the user in the
initial user namespace who builds the container.

e.g. it's easy for a bad inotify container to exhaust real root's inotify
limits with ucounts if the builder itself isn't running as a unique
user. We ended up making the user namespace as the container's kuid
in containerd to deal with that, but with the "no provided uids"
approach you don't have that option from the builder's point of view.

Might be nice to kill the ucount rollup at the initial cell that was
created... can't decide how to deal with that all offhand, I'm sure just
stopping it there has its own issues.

Thanks,
Andrew