On 2025-03-04 14:27:44 +0100, Marc Haber wrote:
> On Tue, Mar 04, 2025 at 01:41:28PM +0100, Vincent Lefevre wrote:
> > On 2025-03-04 10:40:04 +0100, Marc Haber wrote:
> > > On Tue, Mar 04, 2025 at 08:11:10AM +0100, Marc Haber wrote:
> > > > I expect a fix for this adduser issue for later today and
> > > > apologize for the problem. There is no need to debug other
> > > > packages until adduser 3.144 is uploaded.
> > >
> > > Can you try this trivial change?
> >
> > This should work here,
>
> Good. So the RC bug is actually fixed with that.
Well, I don't know whether a system account may have a password,
but this would still fail unexpectedly in such a case.
The adduser(8) man page says:
"adduser --system" does not set a password for the new account.
but it seems that passwd(1) can set a password: its man page says
while the superuser may change the password for any account.
^^^^^^^^^^^^^^^
If a password is forbidden for a system account, then this should
be enforced in passwd(1).
> >but you are not fixing the other issues.
>
> The code in question was contributed by a team member from the US west
> coast who is probably just waking up. I'd rather not interfere with
> their logic here if my minimal change fixes the current RC issue.
>
> I don't think this code path was meant to be invoked in the current,
> pre-trixie state of adduser.
>
> Can you help me by giving a sequence of commands that triggers the issue
> of the wrong logic so that I can put the in an initially failing test
> case before trying to change the code?
1. For a system account, there would still be an issue if the account
has a password (if possible). If EXISTING_ID_MISMATCH is set, this
would also yield an issue; I think that this is possible if the --uid
adduser option is used, with an id different from the current one for
this account. You should add a test for this case.
2. For a non-system account, the problematic test would always be
false, while it is actually meant to be true (the error message
contains "but is not a system user"). So you should add a test
adduser --system username
where the username account already exists and is not a system account
(not sure whether other options, such as --disabled-password, may be
needed). One would expect a non-zero exit status because --system is
used while username exists and is not a system account.
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
