On Wednesday 21 August 2013 10:34:00 Thomas Vajzovic wrote: > In scp.c, there are comments about the requirement to call exec immediately > in the child after vfork returns, and this is done. > > In other places some of the things that are done after vfork but before > exec are quite big, eg: > > * writing to stack data > * writing to global data > * closing and dup-ing file descriptors > * changing signal handlers > * writing to the login record > * malloc-ing memory > * setting environment variables > * setuid/setgid > > In svr-chansession.c the code commented "wipe the hostkey" is not performed > if vfork was used, so presumably that bit was found to not work, but what > about the rest? > > Are people running the dropbear server on no-MMU systems and it just > happens to work for them, or has someone verified that it will always > work?
i've run it on Blackfin w/out too much trouble. although it's been a few years at this point since i last posted patches on the topic to the list. > If people agree that this is wrong, then I could spend some time fixing > it... many of the things you describe aren't a problem (like messing with fd's or signal handlers or changing uids/gids). some of them dropbear works around in other ways. so simply trying to stop it from doing anything at all is not correct. basically, before you start messing with the nommu/vfork nuances, you have to get a good understanding of what the actual Linux semantics vs what the man page states. -mike
signature.asc
Description: This is a digitally signed message part.
