From: Enrico Scholz (enrico.scholz_at_informatik.tu-chemnitz.de)
Date: Tue 28 Dec 2004 - 16:23:18 GMT
sfrost_at_snowman.net (Stephen Frost) writes:
>> [... absolute paths vs. resolution with $PATH ...]
>> 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?
rebooting with 'vshelper' might have a setuid-like effect...
> What if the root user is running it and *wants* . in his path for
> some testing work?
Having '.' in $PATH results in undefined behavior when non-absolute
programnames are used. I do not want undefined behavior...
> If a hostile person has root access in the guest server, what if they
> just replaced the binaries themselves?
One problem is:
| $ vserver foo start
| ...
| cd /vservers/foo/...
| mount /blahblub '.'
When root has still '.' in $PATH (which was set e.g. for the "testing
work" above), you could give root-access for the host-system to the
guest-admin also...
When executing
| /bin/mount /blahblub '.'
things are ok.
> Or created an alias/function in root's .profile? ...
util-vserver should/must not use anything in the guest-system. Using
absolute paths is part of the strategy to avoid this.
>> 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.
1. I do not ship binaries
2. I do not believe into the one-binary-for-all-distributions concept
It is free software; everybody can recompile it in his/her environement
or use packages for the used environment/distribution.
Enrico
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver