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 <farmat...@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 */ > } > > > > > > > > _______________________________________________ > busybox mailing list > busybox@busybox.net > http://lists.busybox.net/mailman/listinfo/busybox >
_______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
