[Adduser-devel] Bug#774046: [adduser] weak username check provided by --force-badname does not match useradd capability

Stephen Lyons slysven at virginmedia.com
Sun Dec 28 00:27:40 UTC 2014


Package: adduser
Version: 3.113+nmu3
Severity: normal
Tags: patch

--- Please enter the report below this line. ---
In the man page for this command is written:
>   --force-badname 
>          By default, user and group names are checked against the
>          configurable regular expression NAME_REGEX specified in       
>          the configuration file. This option forces adduser and
>          addgroup to apply only a weak check for validity of the
>          name.
Also:
> root at Kirk:/home# adduser --help
> adduser [--home DIR] [--shell SHELL] [--no-create-home] [--uid ID]
> [--firstuid ID] [--lastuid ID] [--gecos GECOS] [--ingroup GROUP | --gid ID]
> [--disabled-password] [--disabled-login] USER
>    Add a normal user
> 
> adduser --system [--home DIR] [--shell SHELL] [--no-create-home] [--uid ID]
> [--gecos GECOS] [--group | --ingroup GROUP | --gid ID] [--disabled-password]
> [--disabled-login] USER
>    Add a system user
> 
> adduser --group [--gid ID] GROUP
> addgroup [--gid ID] GROUP
>    Add a user group
> 
> addgroup --system [--gid ID] GROUP
>    Add a system group
> 
> adduser USER GROUP
>    Add an existing user to an existing group
> 
> general options:
>   --quiet | -q      don't give process information to stdout
>   --force-badname   allow usernames which do not match the
>                     NAME_REGEX configuration variable
>   --help | -h       usage message
>   --version | -v    version number and copyright
>   --conf | -c FILE  use FILE as configuration file
> 

It is not obvious what that weak check *IS* however the --help
reiterates that --force-badname should bypass the NAME_REGEX
configuration variable - which I found (commented out) lurking at the
bottom of /etc/adduser.conf:
> root at Kirk:/home# tail -4 /etc/adduser.conf
>
> 
> # check user and group names also against this regular expression.
> #NAME_REGEX="^[a-z][-a-z0-9_]*\$"
I have found that what is accepted does not include accented characters
when encoded in Utf-8.  Perusing the Perl code for this command reveals
this:
> # checkname: perform some sanity checks
> # parameters:
> #   none
> # return values:
> #   none (exits on error)
> sub checkname {
>     my ($name) = @_;
>     if ($name !~ /^[_.A-Za-z0-9][-\@_.A-Za-z0-9]*\$?$/) {
> 	printf STDERR
> (gtx("%s: To avoid problems, the username should consist only of
> letters, digits, underscores, periods, at signs and dashes, and not start with
> a dash (as defined by IEEE Std 1003.1-2001). For compatibility with Samba
> machine accounts \$ is also supported at the end of the username\n"), $0);
>         exit RET_INVALID_CHARS_IN_NAME;;
>     }
>     if ($name !~ qr/$config{"name_regex"}/) {
>       if ($allow_badname) {
> 	print (gtx("Allowing use of questionable username.\n")) if ($verbose);
>       }
>       else {
>         printf STDERR
> (gtx("%s: Please enter a username matching the regular expression configured
> via the NAME_REGEX configuration variable.  Use the `--force-badname'
> option to relax this check or reconfigure NAME_REGEX.\n"), $0);
>         exit RET_INVALID_CHARS_IN_NAME;
>       }
>     }
> }
so this suggests that the pertinent expression is:
[_.A-Za-z0-9][-\@_.A-Za-z0-9]*\$?$

However this seems unduly strong for a *weak* check when compared to the
documentation for the useradd ELF-executable, in particular in the
CAVEATS section is:
> It is usually recommended to only use usernames that begin with a lower case
> letter or an underscore, followed by lower case letters, digits, underscores,
> or dashes. They can end with a dollar sign. In regular expression terms:
> [a-z_][a-z0-9_-]*[$]?
> 
> On Debian, the only constraints are that usernames must neither start with a
> dash('-') nor plus ('+') nor tilde ('~') nor contain a colon (':'), a comma
> (',') or a whitespace (space: ' ', end of line: '\n', tab: '\t', etc.) Note
> that using a slash ('/') may break the default algorithm for the definition
> of the user's home directory.
> 
> Usernames may only be up to 32 characters long.

Sadly, I am not a Perlmunger, but it strikes me that if anyone can
express the above and plug it into that first "if" in the Perl
sub-routine then, on principle of least surprise, what adduser will
accept if *forcible* *told* *to* will actually match what useradd will
handle.

I originally had a much stronger worded post about how adduser seems to
be broken because "adduser --force-badname cáfé" would not work as
described and how by commenting out that 8-line "if" in the Perl
sub-routine I *was* able to create such a user with accented characters.
I now realise that adduser is a Debian wrapper around useradd and it
enforces (or is supposed to) Debian policies - however it still seems
that the documentation could be clearer than it is.

The reason for my raising this is that I am working on a project that
runs on a range of OSs - some of which make no claim to meet
POSIX.1-2008 {that outfit based in Redmond, Washington for instance}
however THAT system permits users to have usernames containing accented
characters - not entirely unreasonable in my opinion, as not everyone in
the world does have a name that can be written with just the ASCII
character set.  This translates into them having home directories that
also contain those characters and we are finding that our project is
breaking for them because it uses files on paths involving their home
directory to save data specific to them.  Not having direct access to a
development environment in THAT Operating System I felt I should be able
to simulate the experiences affected users were having by creating test
accounts with the same name on my favourite OS: Debian GNU/Linux only to
find that I couldn't or at least not without reaching into the internals
and yanking a few things around.

Whilst I recognise that non-ASCII user names being generally accepted
through out a GNU/Linux OS is going to be a wish-list item for the
foreseeable future, adjusting the behaviour of adduser to work to the
limits of the underlying infrastructure "when told to" does not seem so
unreasonable IMHO.

Stephen
--- System information. ---
Architecture: i386
Kernel:       Linux 3.14-0.bpo.2-rt-686-pae

Debian Release: 7.7
[deliberately removed]

--- Package information. ---
Depends             (Version) | Installed
=============================-+-==============
perl-base          (>= 5.6.0) | 5.14.2-21+deb7u2
passwd          (>= 1:4.0.12) | 1:4.1.5.1-1
debconf                       | 1.5.49
 OR debconf-2.0               |


Package's Recommends field is empty.

Suggests                    (Version) | Installed
=====================================-+-===========
liblocale-gettext-perl                | 1.05-7+b1
perl-modules                          | 5.14.2-21+deb7u2





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/adduser-devel/attachments/20141228/45fd9d23/attachment.sig>


More information about the Adduser-devel mailing list