On Mon, 2005-08-22 at 12:24 -0700, Zac Medico wrote:
> warnera6 wrote:
> >>> My preference would go 4, 3, 2 then 1. While Makefiles and configure
> >>> scripts may be "broken" upstream, how long is it before the breakage
> >>> goes unnoticed? More importantly, what's the chances of a dev finding
> >>> the breakage before users? Cleansing the environment to me is akin to
> >>> using sandbox. It offers protection against misbehaving packages...
> >>>
> >>
> >> Good point. How about if we add environment sandboxing support (in
> >> addition to filesystem sandboxing) to sandbox. With an environment
> >> sandbox, we could detect specifically which variables a build is
> >> fragile with regard to. The sandbox would have both filesystem access
> >> and environment access violation summaries.
> >
> > "environmental sandbox" being similar to sandbox, or the cleansing of
> > the environment? The latter is easy, the former...I am not sure how you
> > begin to detect variable use in bash :/
> >
>
> AFAIK we can intercept getenv() calls the same way that we intercept
> filesystem calls. IMO the white/black/override lists would best be
> implemented at this level.
getenv is'nt a system call. It is in the section 3 of the manual and I
tried this:
#include <unistd.h>
int main ()
{
getenv("USER");
return 0;
}
// $ strace ./test 2>&1 | grep USER
// $ strace ./test 2>&1 | grep foo # where $USER=foo
and both output is empty. I have'nt checked how sandbox is working for
filesystem, but filesystem related calls are at somepoint forwarded to
the kernel and that is probably where sandbox is hooking. But as getenv
is'nt a syscall, you could probably could probably find a way to get it
to working by not linking on libc, define getenv and load libc with
dlopen, but that will be a pain. As you need to libc to get your main
called.
Kristian
--
[email protected] mailing list
