On Tue, 29 Oct 2024 at 11:43:48 +0100, Marc Haber wrote:
> On Mon, Jul 01, 2024 at 10:38:55AM +0100, Simon McVittie wrote:
> > For example adduser could check for CAP_SYS_ADMIN and only use --id
> > if that capability is available
>
> What would I need to do to have a test case to check wether adduser will
> work without privileges? setpriv --inh-caps -SYS_ADMIN --bounding-set
> -SYS_ADMIN is not going to work since adduser needs privileges to create
> users, right?

Running as

    setpriv --bounding-set -SYS_ADMIN adduser somebody

in a Debian sid VM with systemd init seems to be a sufficient reproducer
for this.

adduser needs privileges, but not *that* privilege, at least when using
the typical /etc/shadow backend for user/password storage, otherwise it
wouldn't work in a default podman configuration:

    $ podman pull debian:sid-slim
    $ podman run --rm -it debian:sid-slim
    # setpriv --dump
    …
    Capability bounding set: 
chown,dac_override,fowner,fsetid,kill,setgid,setuid,setpcap,net_bind_service,sys_chroot,setfcap
    # apt update
    # apt install adduser
    …
    Setting up adduser (3.137) ...
    # adduser somebody
    …
    Is the information correct? [Y/n] y
    info: Adding new user `somebody' to supplemental / extra groups `users' ...
    info: Adding user `somebody' to group `users' ...

> it might actually be possible to solve this issue by
> 
> - piping logger's stderr to /dev/null
> - using Sys::Syslog in preference over logger if Sys::Syslog is
>   available
> - check for CAP_SYS_ADMIN and fall back to logger without --id if not

I don't have a strong preference between those options, especially the
last two. I'd slightly prefer not the first one, because that could hide
genuine problems with logger - although adduser's use of logger is not
critical-path for adduser's own functionality anyway.

Sys::Syslog is in libperl5.40, and perl is Priority: standard, so
non-minimal systems will generally have it installed anyway.

> Adduser could also offer a logger preference, including a "none" option
> making the logging a no-op.

I'd prefer it to "do the right thing" by default, rather than requiring
special options to avoid unnecessary noise when running in a container
(which would require callers to be aware of whether they might be in
a container).

> I filed #1086233 [in bsdutils]

Thanks, that seeems appropriate.

    smcv

Reply via email to