Control: tags -1 confirmed
thanks

Hi,

sorry for taking so long to reply.

On Mon, Jul 01, 2024 at 10:38:55AM +0100, Simon McVittie wrote:
> I see that either `logger id` exits with status 0 or `adduser` ignores
> a nonzero exit status, so in fact the only reason this fails is that
> autopkgtest is being extra-careful and refusing to continue if its
> create-normal-user script produces output on stderr.

logger --id exits with a zero exit code after writing the error message
to stderr. Adduser checks for the zero exit code and happily continues.

> With autopkgtest hat on, I would prefer not to make it add CAP_SYS_ADMIN,
> so that we can be somewhat confident that the code under test cannot escape
> from the container (or at least that if it could, that would be treated as
> a podman security vulnerability).

Agreed.

> > I am unsure whether this should be considered a bug in adduser
> 
> I think it should (let's use the cloned bug for this).
> 
> For example adduser could check for CAP_SYS_ADMIN and only use --id
> if that capability is available, or it could log via Sys::Syslog if
> available (falling back to stderr or to logger(1) without --id if the
> full perl package isn't installed).

That is something we could do from the adduser side.

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?

Adduser is not using Sys::Syslog on purpose to avoid the dependency. But
our new logger code (log_to_syslog in AdduserLogging.pm) is encapsulated
nicely so 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.

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

What is your opinion about that?

> It could also be argued that this is a logger (util-linux) bug, because
> logger(1) says "otherwise the socket credentials are not modified and
> the problem is silently ignored", but this bug report indicates that
> the problem is in fact not *silently* ignored.

I filed #1086233

Greetings
Marc

Reply via email to