From: Stephen Frost (sfrost_at_snowman.net)
Date: Tue 28 Dec 2004 - 14:05:16 GMT
* Enrico Scholz (enrico.scholz_at_informatik.tu-chemnitz.de) wrote:
> sfrost_at_snowman.net (Stephen Frost) writes:
> > So, it's used by scripts *and* is compiled into programs?
> Yes; e.g.
I believed you, I just find it kind of ugly. :)
> > I'm thinking it might go in /usr/share/util-vserver then, since it's
> > not system-dependent
> it is system-dependent; e.g. on i386 it has
ehh, alright, the example you gave isn't actually how it works out on
Debian currently (amd64 is pure64, which means /usr/lib and no lib64)
but perhaps there's other things, it's not a big deal,
/usr/lib/util-vserver is fine too.
> >> * execve(2) is more efficiently than execvp(3)
> > Is there something in here that actually would notice from such a
> > change? Seriously, is there *really* some benefit here for an end user
> > or is this just a lame excuse thrown in at the end? :P
> using execvp(3) would mean:
> * trusting in $PATH that it contains the wanted path (this has to deal
> with packaging philosophies also which expect all 3rd party apps
> under /opt/<name>) --> /etc/profile.d/* et.al. must be executed
> before everything else
> * trusting in $PATH that it contains not too much (e.g. no '.'); we are
> operating in hostile environments (guest-servers) --> sanity checks
> for $PATH are required
> * iterating over all elements of $PATH and try execve() there
> With execve(2) you do not have these problems and both coding and
> runtime-executing is more efficiently.
Alright, you've jumped from a performance issue to being concerned
about security. So, let's talk about security then-
Who's going to run the programs? Are any of them setuid? What if the
root user is running it and *wants* . in his path for some testing work?
If a hostile person has root access in the guest server, what if they
just replaced the binaries themselves? Or created an alias/function in
root's .profile? Should a root user in a guest server even be able to
change context anyway? Lack of the binaries wouldn't stop someone who
has root in a vserver from being able to download the appropriate
binaries and if that allowed them to break out of the vserver there'd be
a more serious problem here I'd think.
> I do not see an advantage in guessing paths with execvp(3) over and over
> again, when they can be determined at buildtime.
The problem is that you're not building on every box out there- you're
building on one box and then shipping binary files which can't be
changed very easily. Therefore, being flexible is generally preferred,
especially when you're talking about paths to other programs which the
admin may want to install his own utilities for, for whatever reason.
Vserver mailing list