[RFC] malloced getpw/grxxx/_r functions for bb

tito farmatito at tiscali.it
Wed Aug 20 20:08:01 UTC 2014


On Monday 18 August 2014 21:50:44 tito wrote:
> On Tuesday 05 August 2014 20:16:04 Denys Vlasenko wrote:
> > On Mon, Aug 4, 2014 at 7:06 PM, Laszlo Papp <lpapp at 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
> 
> 
> 
> 
> 
Hi,
v 0.2 memory leaks reduced and better checking of leading/trailing whitespace and empty fields in records.

Ciao,
Tito

=9068== LEAK SUMMARY:
==9068==    definitely lost: 28 bytes in 2 blocks
==9068==    indirectly lost: 0 bytes in 0 blocks
==9068==      possibly lost: 12 bytes in 1 blocks
==9068==    still reachable: 0 bytes in 0 blocks
==9068==         suppressed: 0 bytes in 0 blocks
==9068== 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: pwdgrp.c
Type: text/x-csrc
Size: 11199 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20140820/293da8a4/attachment.c>


More information about the busybox mailing list