Sam Steingold wrote:
> > If I did this, the risk that a bug does not get reported would be too
>
> down with the nannies!
> let us assume that I threw in the anti-totalitarian-programming
> diatribe here. :-)
I call it collaborative programming: I program something, and users report
bugs, until the code gets better. :-)
> > high. For the average user, abort() is acceptable. (Note the module
> > is not suitable for use in libraries.)
>
> then it is not suitable for clisp either.
>
> you could easily make it suitable for libraries too by returning an
> exit code
The point is not the return code. It's about the amount of things that
you have to check in order to be sure that you are not distributing a
security vulnerability.
For the idpriv-drop module the doc says (thanks James!):
Note: There may still be security issues if the privileged task puts
sensitive data into the process memory or opens communication channels
to restricted facilities.
For the idpriv-droptemp module it's even worse:
there are additionally the dangers that
- Any bug in the non-privileged part of the program may be used to
create invalid data structures that will trigger security
vulnerabilities in the privileged part of the program.
- Code execution exploits in the non-privileged part of the program may
be used to invoke the function that restores high privileges and then
execute additional arbitrary code.
In the situation of a library you cannot foresee, not even check, the
possible interactions of the sensitive data structures and the code outside -
because by definition, the code outside is not limited to your source
repository.
That's why these two modules make sense only in executables, and the second
one only in *small* executables which you completely overlook.
Bruno
