[EMAIL PROTECTED] (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 [email protected] http://list.linux-vserver.org/mailman/listinfo/vserver
