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