On Sun, May 03, 2015 at 11:59:29AM +0200, Nicolas George wrote: > On the other hand, that means that the HTTP proxy would be configured at two > different places. This is rarely a good idea, because one day the > configuration will change, and one of the places will be forgotten.
This is inevitable with http_proxy, sadly, as there is no one place you can put things that will guarantee that all processes with get them as environment variables, and no guarantee that all processes will honour http_proxy anyway. The only alternative would be to set up and manage transparent proxying, with a whole load of other drawbacks. > Also: keeping the setting from the environment SHOULD WORK. If it does not, > there is a problem that needs fixing. Any other solution is not a fix, it is > a work-around. There are drawbacks to doing it. With -E it's potentially passing dangerous environment variables up to the super process. With whitelisting the http_proxy you're exposing yourself to attacks where a malicious person/process/whatever can point apt (or other things) at a malicious http_proxy. Note that the env whitelisting feature in sudo doesn't restrict what the value of the environment variables can be. Safer, if one is determined to solve this within sudo, would be to use env_file and define the http proxy in a file somewhere, such as /etc/environment. Using 'sudo apt-get -o Acquire::http::Proxy=...' is so laborious that the user is almost guaranteed to define a bash function or alias or something else to save on typing. By which point they may as well have put it in the apt configuration. > I do not know if the order if the directives in /etc/sudoers matters, as was > suggested earlier, but that would be the first thing to try. And of course, > use env to test, not apt. They don't, for aliases, but they do for user specifications. I believe the env_* options are considered aliases. See man sudoers for the fine details. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150503125857.ge29...@chew.redmars.org
