How do you prove that your rewrite from scratch is robust?
On Mon, Aug 18, 2014 at 8:50 PM, tito <farmat...@tiscali.it> wrote: > On Tuesday 05 August 2014 20:16:04 Denys Vlasenko wrote: >> On Mon, Aug 4, 2014 at 7:06 PM, Laszlo Papp <lp...@kde.org> wrote: >> > 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 >> >> Both issues come from the same location in codebase: >> bb__pgsreader() parser drops lines which are longer than its buffer. >> >> Effectively, bbox ignores offending line in /etc/passwd. >> >> > Could you please look into this and potentially fix it? Thanks in advance. >> >> Anyone willing to rewrite getpwnam API to use variable-sized malloced buffer? > > Hi, > i couldn 't resist as I was sure there was a lot to learn and so I've started > to reinvent the wheel. At first I've tried to modify the original bb > implementation > but the code with its preprocessor black magic made it difficult so I've > started > from scratch. > At the moment I have a proof of concept implementation for: > > getpwuid > getgrgid > getpwnam > getgrnam > getpwuid_r > getgrgid_r > getpwnam_r > > The code is ugly and probably bloated for bb so look at it at your own risk > :-) > > Other functions still missing but used in bb: > fgetpwent_r > fgetgrent_r > getspnam_r > setpwent > endpwent > setgrent > endgrent > getpwent_r > getgrent_r > initgroups > > What it does: > 1) the buffer for getpwuid, getgrgid, getpwnam, getgrnam is dynamically > allocated and reused by later calls. if ERANGE error pops up it is > reallocated to the _NEEDED_ size and reused for later calls. > > 2) the fields in the passwd files are checked and if empty (in some cases) or > containing > whitespace, etc. a error message about malformed line in file xxxxxx > is printed so that the user knows instead of being silently ignored. > > 3) the _r functions use the user supplied buffers that are never reallocated > but use mostly the same common functions. > > 4) there was something........ > > Before going further some review and improvements (size reduction, obvious > errors, bugs > and other horrors) by the list members is needed and also some hints if this > implementation > makes sense at all or if I should forget about it. > > My biggest problem at the moment is a memory leak in handling the members in > group->gr_mem and I don't see a obvious way to fix it. > > The proof of concept is developed out of tree in the pwdgrp.c file that > contains also > a test program to grossly check if everything works. The relevant libbb > functions are > copied over to the libbb.c file which is included automatically. You can > compile it simply by: > > gcc pwdgrp.c -o test -Wall > > > valgrind of a test run shows: > > =7229== HEAP SUMMARY: > ==7229== in use at exit: 272 bytes in 4 blocks > ==7229== total heap usage: 22 allocs, 18 frees, 4,012 bytes allocated > ==7229== > ==7229== 68 bytes in 1 blocks are still reachable in loss record 1 of 4 > ==7229== at 0x4028308: malloc (vg_replace_malloc.c:263) > ==7229== by 0x402849F: realloc (vg_replace_malloc.c:632) > ==7229== by 0x80489E4: xrealloc (in /home/tito/Desktop/test) > ==7229== by 0x8048A5C: xrealloc_vector_helper (in /home/tito/Desktop/test) > ==7229== by 0x8049584: convert_to_grp (in /home/tito/Desktop/test) > ==7229== by 0x80498AB: my_getgr_common (in /home/tito/Desktop/test) > ==7229== by 0x80498FE: my_getgrgid (in /home/tito/Desktop/test) > ==7229== by 0x8049EBD: main (in /home/tito/Desktop/test) > ==7229== > ==7229== 68 bytes in 1 blocks are definitely lost in loss record 2 of 4 > ==7229== at 0x4028308: malloc (vg_replace_malloc.c:263) > ==7229== by 0x402849F: realloc (vg_replace_malloc.c:632) > ==7229== by 0x80489E4: xrealloc (in /home/tito/Desktop/test) > ==7229== by 0x8048A5C: xrealloc_vector_helper (in /home/tito/Desktop/test) > ==7229== by 0x804953E: convert_to_grp (in /home/tito/Desktop/test) > ==7229== by 0x80498AB: my_getgr_common (in /home/tito/Desktop/test) > ==7229== by 0x80498CD: my_getgrnam (in /home/tito/Desktop/test) > ==7229== by 0x8049D43: main (in /home/tito/Desktop/test) > ==7229== > ==7229== 68 bytes in 1 blocks are definitely lost in loss record 3 of 4 > ==7229== at 0x4028308: malloc (vg_replace_malloc.c:263) > ==7229== by 0x402849F: realloc (vg_replace_malloc.c:632) > ==7229== by 0x80489E4: xrealloc (in /home/tito/Desktop/test) > ==7229== by 0x8048A5C: xrealloc_vector_helper (in /home/tito/Desktop/test) > ==7229== by 0x804953E: convert_to_grp (in /home/tito/Desktop/test) > ==7229== by 0x804976C: getgr_common_r (in /home/tito/Desktop/test) > ==7229== by 0x80497B9: my_getgrnam_r (in /home/tito/Desktop/test) > ==7229== by 0x8049E0A: main (in /home/tito/Desktop/test) > ==7229== > ==7229== 68 bytes in 1 blocks are definitely lost in loss record 4 of 4 > ==7229== at 0x4028308: malloc (vg_replace_malloc.c:263) > ==7229== by 0x402849F: realloc (vg_replace_malloc.c:632) > ==7229== by 0x80489E4: xrealloc (in /home/tito/Desktop/test) > ==7229== by 0x8048A5C: xrealloc_vector_helper (in /home/tito/Desktop/test) > ==7229== by 0x804953E: convert_to_grp (in /home/tito/Desktop/test) > ==7229== by 0x804976C: getgr_common_r (in /home/tito/Desktop/test) > ==7229== by 0x8049806: my_getgrgid_r (in /home/tito/Desktop/test) > ==7229== by 0x8049F84: main (in /home/tito/Desktop/test) > ==7229== > ==7229== LEAK SUMMARY: > ==7229== definitely lost: 204 bytes in 3 blocks > ==7229== indirectly lost: 0 bytes in 0 blocks > ==7229== possibly lost: 0 bytes in 0 blocks > ==7229== still reachable: 68 bytes in 1 blocks > ==7229== suppressed: 0 bytes in 0 blocks > > > Ciao, > Tito > > > > > > _______________________________________________ > 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
