Re: [PATCH v4] kernel: Conditionally support non-root users, groups and capabilities

[josh@joshtriplett.org]

On Fri, Feb 20, 2015 at 04:11:32PM -0800, Andrew Morton wrote:
> On Wed, 11 Feb 2015 17:03:36 +0200 Iulia Manda <iulia.manda21@gmail.com> wrote:
> 
> > There are a lot of embedded systems that run most or all of their functionality
> > in init, running as root:root. For these systems, supporting multiple users is
> > not necessary.
> > 
> > This patch adds a new symbol, CONFIG_MULTIUSER, that makes support for non-root
> > users, non-root groups, and capabilities optional. It is enabled under
> > CONFIG_EXPERT menu.
> > 
> > When this symbol is not defined, UID and GID are zero in any possible case
> > and processes always have all capabilities.
> > 
> > The following syscalls are compiled out: setuid, setregid, setgid,
> > setreuid, setresuid, getresuid, setresgid, getresgid, setgroups, getgroups,
> > setfsuid, setfsgid, capget, capset.
> > 
> > Also, groups.c is compiled out completely.
> > 
> > In kernel/capability.c, capable function was moved in order to avoid adding two
> > ifdef blocks.
> > 
> > This change saves about 25 KB on a defconfig build.
> > 
> > The kernel was booted in Qemu. All the common functionalities work. Adding
> > users/groups is not possible, failing with -ENOSYS.
> > 
> > Bloat-o-meter output:
> > add/remove: 7/87 grow/shrink: 19/397 up/down: 1675/-26325 (-24650)
> 
> The objective seems OK to me - in some kernel applications non-root
> users are never needed and it's better to not force those systems to
> carry a lump of code they will never use.

Thanks!

> How significant is the 25k saving?  On a realistic kernel build for
> such a target, what proportion of kernel memory usage are we talking
> about here?

Quite significant; the most minimal kernels have total text sizes in the
high hundreds of kB rather than low MB.  (The 25k goes down a bit with
allnoconfig, but not that much IIRC.)

> Did you look at moving sys_setregid into groups.c (or elsewhere) to
> save an ifdef?

The syscalls compiled out of sys.c also include the *uid syscalls, not
just gid syscalls.  Also, groups.c currently includes exclusively the
functionality for supplementary groups; mixing other uid or gid
functionality into that seems wrong.

> I assume that more savings can be squeezed out - there will be fields
> in the task_struct and other places which will never be used.  ifdefing
> those out will get messy.  Have you done any investigation here?

Just enough to figure out that it'd be a much larger and more invasive
patch for much less gain.  On a system that doesn't need non-root users,
there are hopefully very few processes and thus very few copies of
task_struct; likewise for other structures containing credential data.

Iulia and I talked about that one and ended up coming to the conclusion
that we should wait for compiler support that makes it easier to omit
struct fields (e.g. an attribute that says "omit this field, turn writes
into no-ops, make reads either return this compile-time constant or
produce an error").

- Josh Triplett