From owner-freebsd-bugs@freebsd.org Sat Apr 4 03:47:14 2020 Return-Path: Delivered-To: freebsd-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1F9FD27D2CC for ; Sat, 4 Apr 2020 03:47:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 48vN691GJgz4Jkw for ; Sat, 4 Apr 2020 03:47:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 518F027D2A0; Sat, 4 Apr 2020 03:47:05 +0000 (UTC) Delivered-To: bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 389A627D29F for ; Sat, 4 Apr 2020 03:47:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48vN5z3G5Yz4JhS for ; Sat, 4 Apr 2020 03:47:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id B63CD1925B for ; Sat, 4 Apr 2020 03:13:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 0343DdVx065552 for ; Sat, 4 Apr 2020 03:13:39 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 0343DdED065548 for bugs@FreeBSD.org; Sat, 4 Apr 2020 03:13:39 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 245342] adduser.sh silently sets a password different from the input if it contains leading/trailing spaces Date: Sat, 04 Apr 2020 03:13:39 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: mario.baldini@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2020 03:47:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D245342 Bug ID: 245342 Summary: adduser.sh silently sets a password different from the input if it contains leading/trailing spaces Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: bugs@FreeBSD.org Reporter: mario.baldini@gmail.com Hello all,=20 TL;DR;=20 `adduser.sh` script silently leads to unexpected system configuration if the password contains leading or trailing space. It ends successfully, but configuring the account with a password different from what was input by the user. The behavior is not clearly informed to the user (during the process itself; nor in the Handbook).=20 Steps to reproduce: (tested on FreeBSD 13.0) - Create a user account with `useradd` (ie. during the installation process) - In the user password insertion, provide one with leading/trailing space - Attempt to login afterward, with the previously inserted password - Error: login not possible due wrong password (can be confirmed by providing the same string but without the leading/trai= ling password, it will login as expected) Expected behavior:=20 - Password set process should support leading/trailing spaces; - Or explicitly warn the user and request a different password (but not pro= ceed silently defining a password that was not the input (and confirmed) string) Accordinly to line 736 of freebsd/usr.sbin/adduser/adduser.sh=20 echo -n "Enter password: " read -r upass echo'' echo -n "Enter password again: " read -r _passconfirm and `bash` documentation `read` section: The trailing newline is deleted from the line and the line is split as described in the section on White Space Splitting (Field Splitting) above, = and the pieces are assigned to the variables in order. (...) White Space Splitting:=20 Whitespace in IFS at the beginning or end of a word is discarded. Apparently, removing any leading/trailing space is the expected behavior of `read -r upass` command itself, but should not be the expected one of the `adduser.sh` process as a whole. Also, the FreeBSD Handbook `3.3.2.1. addus= er` or `Example 3.2, =E2=80=9CAdding a User on FreeBSD=E2=80=9D` do not mention= this. In a new install the user may simply complete it without any error and later be lock= ed out of the machine in this scenario. (I eventually just found guessing the issue and trying the pwd without the spaces). I guess the process workings itself should not be changed (since it conflic= ts with the regular `read` "word split" behavior), also due being an edge case. But in any case, the user should be adequately informed and the process continued only if the string set as the pwd to be exacly what the user inse= rted (and confirmed). PS: I search the bugzilla archive and other forums but did not find any previous discussion that addresses this particular case. Please let me know= if there is a better channel or I am misunderstanding something about adduser script.=20 Thank you all, Best regards, Mario Baldini Error logs: /bin/sh $ sudo adduser Username: somename Full name: Some Uid (Leave empty for default):=20 Login group [somename]:=20 Login group is somename. Invite somename into other groups? []:=20 Login class [default]:=20 Shell (sh csh tcsh zsh rzsh git-shell bash rbash nologin) [sh]:=20 Home directory [/home/somename]:=20 Home directory permissions (Leave empty for default):=20 Use password-based authentication? [yes]:=20 Use an empty password? (yes/no) [no]:=20 Use a random password? (yes/no) [no]:=20 Enter password:=20 Enter password again:=20 Lock out the account after creation? [no]:=20 Username : somename Password : ***** Full Name : Some Uid : 1002 Class :=20 Groups : somename=20 Home : /home/somename Home Mode :=20 Shell : /bin/sh Locked : no OK? (yes/no): yes adduser: INFO: Successfully added (somename) to the user database. Add another user? (yes/no): no Goodbye! $=20 # - user account was created successfully # - the password set for is is different from what was input (if the input contained leading/trailing space) # - user is not aware of this mismatch --=20 You are receiving this mail because: You are the assignee for the bug.=