They were order of magnitude more problematic when multi-user machines were the norm.
True enough, but it is still the case, for a good definition of "user". Most machines today only have one human user, but there are a lot of uids and gids used to run daemons with separate privileges. It is just as likely that an exploitable hole will be found in some daemon code than in some code directly run under the human user's uid - and there, a "user" exploit won't be a major problem, whereas a root exploit will.
It is not logical anymore to see root exploits as orders of magnitude more dangerous than user-level ones, and spend much more efforts to prevent specifically these exploits to be used. If you are afraid that ping may have a bug, spend time auditing ping, not making it more ugly just because you can make such bug impact "only lowly user".
I understand what you're saying, and agree with it, but my point is that my solution: * isn't much more effort. I probably spent 5-10 minutes writing the additional 4 lines of C code. And theoretically, the privileged applet list could be automatically generated from the Kconfig, to avoid any additional configuration effort. * isn't more ugly. Actually, there's less code in total than with the busybox setuid-then-drop-privileges thing, and the general case execution path is shorter. It could totally be integrated into busybox itself and benefit everyone. I just don't have time to work on a patch right now, so I'm just mentioning the idea around. -- Laurent _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
