adduser/passwd: too long username

Laszlo Papp lpapp at kde.org
Tue Aug 5 13:14:20 UTC 2014


On Tue, Aug 5, 2014 at 2:06 PM, tito <farmatito at tiscali.it> wrote:

> On Tuesday 05 August 2014 14:47:53 you wrote:
> > On Tue, Aug 5, 2014 at 1:42 PM, tito <farmatito at tiscali.it> wrote:
> >
> > > On Tuesday 05 August 2014 14:27:57 you wrote:
> > > > I disagree. There is nothing to reject here. It fixes _my issue_ at
> hand.
> > > > If you want to fix other bugs in your system that you are facing in
> > > > reality, by all means, fix them in a separate change.
> > > >
> > > > I definitely do not agree with dynamically allocated buffer for the
> > > simple
> > > > reasons of:
> > > >
> > > > 1) Slow.
> > > > 2) You would still need a maximum anyway.
> > > > 3) Needless code complication.
> > > >
> > > > Let us keep things simple and good, you know the good old KISS
> principle.
> > > >
> > > > P.S.: please do not bikeshed.
> > > >
> > > >
> > > > On Tue, Aug 5, 2014 at 1:17 PM, tito <farmatito at tiscali.it> wrote:
> > > >
> > > > > On Tuesday 05 August 2014 12:46:08 you wrote:
> > > > > > Here is my tested fix without being to debug the busybox code, so
> > > only
> > > > > code
> > > > > > reading and understanding were my friends:
> > > > > >
> > > > > > commit 9610650b6ce2a4c1904f78a2dcdb47cad3d2e3d1
> > > > > > Author: Laszlo Papp <lpapp at kde.org>
> > > > > > Date:   Tue Aug 5 11:42:24 2014 +0100
> > > > > >
> > > > > >     Allow 256 bytes long usernames as per Unix standards
> (usually)
> > > > > >
> > > > > > diff --git a/libpwdgrp/pwd_grp.c b/libpwdgrp/pwd_grp.c
> > > > > > index 2060d78..368c252 100644
> > > > > > --- a/libpwdgrp/pwd_grp.c
> > > > > > +++ b/libpwdgrp/pwd_grp.c
> > > > > > @@ -23,8 +23,8 @@
> > > > > >
> > >
>  /**********************************************************************/
> > > > > >  /* Sizes for statically allocated buffers. */
> > > > > >
> > > > > > -#define PWD_BUFFER_SIZE 256
> > > > > > -#define GRP_BUFFER_SIZE 256
> > > > > > +#define PWD_BUFFER_SIZE LOGIN_NAME_MAX+256
> > > > > > +#define GRP_BUFFER_SIZE LOGIN_NAME_MAX+256
> > > > > >
> > > > > >
> > >
>  /**********************************************************************/
> > > > > >  /* Prototypes for internal functions. */
> > > > > >
> > > > >
> > > > > Hi,
> > > > > yes I've thought also about this solution but rejected it because:
> > > > >
> > > > > 1) there will not be enough space to hold the home dir if named the
> > > same
> > > > > as the user
> > > > >     so you need at least:
> > > > >
> > > > > #define PWD_BUFFER_SIZE LOGIN_NAME_MAX+ 6 (for home) +
> LOGIN_NAME_MAX
> > > (or
> > > > > PATH_MAX?) + 256 (for the rest)
> > > > >
> > > > >    yet this might not be enough as in my passwd file I see a 101
> char
> > > long
> > > > > passwd.
> > > > >    Add  the gecos fields (arbitrary lenght)  to it and the default
> > > shell
> > > > > and we are short on space again.
> > > > >
> > > > > 2) same for #define GRP_BUFFER_SIZE LOGIN_NAME_MAX+256:
> > > > >     here you need to take into account the group member list with
> > > > >     an arbitrary number of members:
> > > > >
> > > > >
> > > > >     #define GRP_BUFFER_SIZE LOGIN_NAME_MAX+256+ LOGIN_NAME_MAX*n:
> > > > >
> > > > > The only clean solution to fix it forever is dynamically allocated
> > > buffers
> > > > > created at the time you read in the line from the passwd files.
> > > > >
> > > > > Ciao,
> > > > > Tito
> > > > >
> > > > >
> > > > > P.S.: please don't top post.
> > > > >
> > > > >
> > > > > >
> > > > > > On Tue, Aug 5, 2014 at 11:22 AM, Laszlo Papp <lpapp at kde.org>
> wrote:
> > > > > >
> > > > > > > Yeah, mayhaps... Thanks for the prompt reply. I tried to debug
> the
> > > > > code,
> > > > > > > but the busybox code here is a bit messy heavily abusing
> macros in
> > > C
> > > > > and
> > > > > > > all that. It ain't easy I must confess!
> > > > > > >
> > > > > > > For instance, see this section:
> > > > > > >
> > > > > > > http://git.busybox.net/busybox/tree/libpwdgrp/pwd_grp.c#n227
> > > > > > >
> > > > > > > The _source_ is included several times always getting a new
> meaning
> > > > > based
> > > > > > > on some defines... Now, check this function:
> > > > > > >
> > > > > > >
> > > http://git.busybox.net/busybox/tree/libpwdgrp/pwd_grp_internal.c#n20
> > > > > > >
> > > > > > > "resultbuf" will be always different depending on which
> include it
> > > is.
> > > > > > > Since it is failing at the pw_name check in there, I wanted to
> > > print it
> > > > > > > out, but no easy joy there as printing it like that will yield
> > > > > compilation
> > > > > > > error when the file is being included next time from above.
> > > > > > >
> > > > > > > Right, I thought instead of doing some "#if a == b" hackery,
> > > debugging
> > > > > > > would be easier, BUT:
> > > > > > >
> > > > > > > 1) The default build is stripped, yuck!
> > > > > > >
> > > > > > > 2) The unstripped build cannot locate the symbols (*).
> > > > > > >
> > > > > > > So, I am giving up on this for now; this is not the type of
> source
> > > code
> > > > > > > that is so pleasant to work with. ;-)
> > > > > > >
> > > > > > > Cheers, L.
> > > > > > >
> > > > > > > * (gdb) b main
> > > > > > >
> > > > > > > Breakpoint 2 at 0x407c71
> > > > > > > (gdb) r
> > > > > > > Starting program:
> /home/lpapp/Projects/busybox/busybox_unstripped
> > > > > deluser
> > > > >
> > >
> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> > > > > > > warning: Could not load shared library symbols for
> linux-vdso.so.1.
> > > > > > > Do you need "set solib-search-path" or "set sysroot"?
> > > > > > >
> > > > > > > Breakpoint 2, 0x0000000000407c71 in main ()
> > > > > > > (gdb) list
> > > > > > > No symbol table is loaded.  Use the "file" command.
> > > > > > > (gdb)
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Aug 4, 2014 at 10:40 PM, tito <farmatito at tiscali.it>
> > > wrote:
> > > > > > >
> > > > > > >> On Monday 04 August 2014 19:06:39 Laszlo Papp wrote:
> > > > > > >> > Hi,
> > > > > > >> >
> > > > > > >> > sudo busybox adduser
> > > > > > >> >
> > > > > > >>
> > > > >
> > >
> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> > > > > > >> > passwd: unknown user
> > > > > > >> >
> > > > > > >>
> > > > >
> > >
> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> > > > > > >> >
> > > > > > >> > Yet, the user is created in /etc/shadow:
> > > > > > >> >
> > > > > > >> >
> > > > > > >>
> > > > >
> > >
> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff:!:16286:0:99999:7:::
> > > > > > >> >
> > > > > > >> > This is at least one issue, but there is another here:
> > > > > > >> >
> > > > > > >> > sudo busybox deluser
> > > > > > >> >
> > > > > > >>
> > > > >
> > >
> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> > > > > > >> > deluser: unknown user
> > > > > > >> >
> > > > > > >>
> > > > >
> > >
> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> > > > > > >> >
> > > > > > >> > So, basically, once you create that long username, you
> cannot
> > > > > remove it
> > > > > > >> > anymore with busybox and it keeps polluting your system.
> > > > > > >> >
> > > > > > >> > You have to gain other means to clean up! I am using this
> > > version
> > > > > over
> > > > > > >> here:
> > > > > > >> >
> > > > > > >> > BusyBox v1.22.1 (2014-06-02 14:47:37 MSK) multi-call binary.
> > > > > > >> >
> > > > > > >> > Could you please look into this and potentially fix it?
> Thanks
> > > in
> > > > > > >> advance.
> > > > > > >> >
> > > > > > >> > Cheers, L.
> > > > > > >> >
> > > > > > >> Hi,
> > > > > > >> if disabling libb's internal pwd/grp lib and by jumping
> through
> > > some
> > > > > hops
> > > > > > >> it
> > > > > > >> works for me:
> > > > > > >>
> > > > > > >> I need to add the group first as my system's groupadd command
> > > called
> > > > > by
> > > > > > >> bb's adduser
> > > > > > >> supports only groupnames of max 32 chars.
> > > > > > >>
> > > > > > >> ./busybox addgroup
> > > > > > >>
> > > > >
> > >
> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> > > > > > >> ./busybox adduser
> > > > > > >>
> > > > >
> > >
> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> > > > > > >> -G
> > > > > > >>
> > > > >
> > >
> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> > > > > > >> Adding user
> > > > > > >>
> > > > >
> > >
> `fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff'
> > > > > > >> to group
> > > > > > >>
> > > > >
> > >
> `fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff'
> > > > > > >> ...
> > > > > > >> Adding user
> > > > > > >>
> > > > >
> > >
> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> > > > > > >> to group
> > > > > > >>
> > > > >
> > >
> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> > > > > > >> Done.
> > > > > > >> Enter new UNIX password:
> > > > > > >> Retype new UNIX password:
> > > > > > >> passwd: password updated successfully
> > > > > > >>
> > > > > > >> and then I could also delete it:
> > > > > > >>
> > > > > > >> ./busybox deluser
> > > > > > >>
> > > > >
> > >
> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> > > > > > >> ./busybox delgroup
> > > > > > >>
> > > > >
> > >
> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> > > > > > >> delgroup: unknown group
> > > > > > >>
> > > > >
> > >
> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> > > > > > >>
> > > > > > >> (deluser correctly deleted also the group)
> > > > > > >>
> > > > > > >> I suspect that the buffer size used in libbpwdgrp/pwd_grp.c
> is to
> > > > > small:
> > > > > > >>
> > > > > > >> #define PWD_BUFFER_SIZE 256
> > > > > > >> #define GRP_BUFFER_SIZE 256
> > > > > > >>
> > > > > > >> as it is meant for the whole struct pw passwd (or struct gr
> group)
> > > > > fields
> > > > > > >> which could be easily be bigger:
> > > > > > >>
> > > > > > >> grep ffff* /etc/shadow | wc
> > > > > > >>       1       1     240
> > > > > > >> grep ffff* /etc/passwd | wc
> > > > > > >>       1       2     286
> > > > > > >>
> > > > > > >> I think that the buffers' size must be increased for example
> to:
> > > > > > >>
> > > > > > >> #define PWD_BUFFER_SIZE LOGIN_NAME_MAX+LOGIN_NAME_MAX+256
> > > > > > >>
> > > > > > >> we need one LOGIN_NAME_MAX size for the login and one more
> for the
> > > > > home
> > > > > > >> dir
> > > > > > >> if same as login, plus 256 for the remaining data (passwd,
> gecos,
> > > > > shell,
> > > > > > >> etc).
> > > > > > >>
> > > > > > >> #define GRP_BUFFER_SIZE  LOGIN_NAME_MAX+256+LOGIN_NAME_MAX*n
> (?)
> > > > > > >>
> > > > > > >> we need one LOGIN_NAME_MAX size for the group name (for which
> we
> > > > > > >> actually enforce the same size as for the username) plus 256
> for
> > > the
> > > > > > >> remaining data
> > > > > > >> plus LOGIN_NAME_MAX * n group member names.
> > > > > > >>
> > > > > > >> So for my limited understanding using static buffers here is
> > > rather
> > > > > > >> difficult
> > > > > > >> as the size of data is not easily predictable.
> > > > > > >> I don't know how real libc manages it (maybe realloc on
> ERANGE?)
> > > > > > >>
> > > > > > >> Your particular example for me is fixed by using.
> > > > > > >>
> > > > > > >> #define PWD_BUFFER_SIZE 1024
> > > > > > >>
> > > > > > >> #define GRP_BUFFER_SIZE 1024
> > > > > > >>
> > > > > > >> But to me it seems not an optimal solution,
> > > > > > >> so other more experienced developers should
> > > > > > >> take a look at it.
> > > > > > >>
> > > > > > >> Hope this helps.
> > > > > > >> Ciao,
> > > > > > >> Tito
> > > > > > >>
> > > > > > >> PS: in libbbpwdgrp functions we need to check for errors:
> > > > > > >>
> > > > > > >>    0 or ENOENT or ESRCH or EBADF or EPERM or ...
> > > > > > >>               The given name or gid was not found.
> > > > > > >>
> > > > > > >>        EINTR  A signal was caught.
> > > > > > >>
> > > > > > >>        EIO    I/O error.
> > > > > > >>
> > > > > > >>        EMFILE The maximum number (OPEN_MAX) of files was open
> > > already
> > > > > in
> > > > > > >> the calling process.
> > > > > > >>
> > > > > > >>        ENFILE The maximum number of files was open already in
> the
> > > > > system.
> > > > > > >>
> > > > > > >>        ENOMEM Insufficient memory to allocate group structure.
> > > > > > >>
> > > > > > >>        ERANGE Insufficient buffer space supplied.
> > > > > > >>
> > > > > > >> as for example the xgroup_study function in the addgroup
> applet
> > > > > > >> assigns a wrong gid if getgrgid fails for example for ERANGE
> > > > > > >>
> > > > > > >>         /* Check if the desired gid is free
> > > > > > >>          * or find the first free one */
> > > > > > >>         while (1) {
> > > > > > >>                 printf("gid %d\n", g->gr_gid);
> > > > > > >>                 if (!getgrgid(g->gr_gid)) {
> > > > > > >>                         return; /* found free group: return */
> > > > > > >>                 }
> > > > > > >>
> > > > > > >>
> > > Hi,
> > > I doubt it fixes your issue
> >
> >
> > What you are basically telling me here that I submitted untested changes
> > for my use cases, directly or indirectly. Either way, I refuse this claim
> > since I _did_ test the change for my use case.
> >
> >
> > >  because I tested the same fix and it did in fact
> >
> > fail. Please test:
> > >
> > > 1) ./busybox addgroup LONGUSERNAME   (this fails in subtle ways as a
> > > already in use gid is assigned)
> > > 2) ./busybox adduser LONGUSERNAME -G LONGUSERNAME
> > > 3) ./busybox deluser LONGUSERNAME
> > > 4) ./busybox delgroup LONGUSERNAME
> > >
> >
> > I do not see how this is any relevant to my initial steps. This is a
> > completely different test step with a different issue. As I said earlier,
> > please welcome contributors rather than being blocker just because they
> fix
> > one particular and real bug, and not every "imaginary" use case that can
> > just exist in the world out there.
> >
>
> Hi,
> there is nothing imaginary here, i just would like to point out that
> due to the fact that busybox adduser program by default creates
> a home dir with the same name as the user the buffer size you
> propose in your fix may not be big enough to hold all the data
> and that this fact will affect also other commands that use
> the functions in libbbpwdgrp in subtle ways.
> I of course welcome you as a contributor and by the way I have
> no decisional power to accept or reject your patches (which is fine
> for me), but nonetheless sometimes I disagree with you for the sake
> of cleaner solutions (from my point of view).
>

This script disagrees with you:

#!/bin/bash

USERNAME='e'
for i in {1..232}
do
    USERNAME+='f'
done
echo $USERNAME

./busybox adduser -D $USERNAME
./busybox deluser $USERNAME
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20140805/0d05316c/attachment-0001.html>


More information about the busybox mailing list