Stephen Smalley wrote:
On Tue, 2004-10-12 at 10:03, Jeff Johnson wrote:
Better still, how about libselinux_execve() clone. no reason why libselinux
should not do the execve as well afaict.
Hmmm..that lends itself to interface spread, as people will then want
libselinux_execl*, libselinux_execvp, ... and possibly even
libselinux_popen, as opposed to just a setexeccon-like function that can
be called prior to any of those normal calls. We actually had
execve_secure() in the old SELinux API, but were forced to migrate to
setexeccon();execve(); as part of mainstream inclusion.
Interface spread appreciated, but whether application or library does execve(2) is
pehaps not the important issue.
A hook called afetr fork(2) to permit libselinux to change the execution environment opaquely
is what rpm seeks, execve(2) clone is a rather natural way to define the necessary API imho.
But if you want rpm (or application) to do its own execve(2), well, that works too. The issue
for rpm is opaqueness, i.e. not compiling "rpm_script_t" and the decision algorithm into rpmlib.
73 de Jeff
