Re: sudo not respecting /etc/sudoers
Please do not CC me, I am subscribed to the list.
On Sun, May 03, 2015 at 03:36:10PM +0200, Nicolas George wrote:
> Le quartidi 14 floréal, an CCXXIII, Jonathan Dowland a écrit :
> > 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.
> This is true, but completely irrelevant in this case because the discussion
> is not about ALL processes, it is about this particular instance of the
> user's shell and apt-get.
I don't believe it's irrelevant. My ambition in offering advice on the list is
to offer practical advice. If it's a hopeless task to define the http proxy in
just one place, then it's relavant IMHO to suggest it foolhardy to pursue that
> > 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.
> Once again, this is true but irrelevant for this discussion.
Security is always relevant IMHO. We don't know enough of OP's environment
to asses the risk. A safe answer is a more generally useful answer.
> Sanitizing the environment against possible dangerous values is necessary
> when granting LIMITED privileges with sudo, i.e. allowing to run only some
> specific commands with elevated privileges.
> When granting UNLIMITED privileges, i.e. allowing to run any command with
> sudo, sanitizing the environment is just a matter of convenience.
We don't know whether the user shares the box, has other users who are
limited, who would also be affected by the introduction of env_var in sudoers,
nor about anyone else reading, copying or adapting the answer for their own
> And when the address of the proxy will change, they will have a hard
> figuring out what is wrong with apt-get. That is one of the drawback of your
> proposed solution.
That's a good point, apt does not provide adequate diagnostic output when
the proxy server cannot be reached or does not respond. This is a bug that
should be reported, if it hasn't already. This is the same whether you use
-o or not, though. I agree that it's probably going to be more obvious if
you've hand-typed the address at the time of the failure.
> The major drawback, of course, is that you are suggesting a fix without
> having understood the problem first. This is a very bad habit.
I don't know quite how you have come to that conclusion, but regardless of
what you think, this seems needlessly rude. Please try to be civil.