Stephen Smalley wrote:
On Wed, 2004-08-25 at 09:54, Jeff Johnson wrote:
That's the point. Lua is embedded, would be run by rpm, and no re-exec because of internal state.
Ok. And the lua "program" would still be extracted from the (possibly untrustworthy) package contents, as with current helpers like glibc_post_upgrade? So a package can carry arbitrary malicious lua code and get it executed by rpm?
Exactly the same as current rpm behavior, yes.
But thanks for explaining the need for distinguishing rpm_t and rpm_script_t. ;-)
I'll have rpm_script_t into fc3 rpm in a day or two, lua ain't going to happen soon, or suddenly,
or even only from package tag content, in rpm. Almost certainly lua is going to happen in rpm though,
as lua scriptlet support is already in rpm HEAD, and there is a need for embedded scripts in order to accomplish
certain tasks in a near empty chroot without encumbering dependency baggage. That is/was
the original motivation for /usr/sbin/glibc_post_upgrade, not otherwise.
Malicious code from untrusted package problem not going to be solved by rpm_script_t alone afaict either.
And the real problem is that glibc_post_upgrade should not be attempting sshd restart always,
as the need to insure connectivity when modules change occurs only occaisionally, and could
be handled in other ways like, say, documenting an incompatibility or avoiding altogether.
73 de Jeff
