#620927 "sudo aptitude" or "sudo apt-get" can't use proxy settings due to env_reset

Package:
sudo
Source:
sudo
Description:
Provide limited super user privileges to specific users
Submitter:
Josh Triplett
Date:
2026-06-01 05:27:02 UTC
Severity:
normal
Tags:
#620927#3
Date:
2011-04-05 04:08:21 UTC
From:
To:
sudo clears the environment by default.  In particular, this removes any
proxy settings from the environment.  Thus, out of the box, the user
can't configure a proxy the normal way (such as by using the desktop
environment's network proxy settings) and have it work for installing
packages.

Assuming that the default setting of env_reset won't change, please
consider adding the following environment variables to env_keep in the
default sudoers file:

http_proxy https_proxy ftp_proxy all_proxy no_proxy

Thanks,
Josh Triplett

#620927#8
Date:
2015-07-17 11:33:40 UTC
From:
To:
     Hi!

* Josh Triplett <josh@joshtriplett.org> [2011-04-05 06:08:21 CEST]:

 Actually, allowing the user to set a proxy that the system doesn't know
about is a high security risk.  One would be able to set up a dedicated
host which sends vulnerable packages for installations that the user
would be able to install then.  All is needed a snapshot of the archive
a few days before a DSA got fixed and a user having sudo access just for
apt/aptitude could install the vulnerable package then to gain root
access.

 I think it's sane to not allow a user to set a proxy server for
installing packages.  If you can follow my reason feel free to close the
bugreport. :)

 So long!
Rhonda

#620927#13
Date:
2015-07-17 17:25:44 UTC
From:
To:
I'm not suggesting that all sudo configurations should pass through
the proxy environment variables; sudo configurations that offer a very
limited set of commands should not.  (Though it's difficult to create a
sudo configuration that *only* allows installing packages and doesn't
end up giving effective root equivalence.)

With the default sudo configuration, if you're in group sudo, you can
already "sudo -E" to preserve the environment; you can also run "sudo
env ..." or just "sudo VAR=value ..." to set arbitrary environment
variables.  sudo allows users permitted to run "ALL" to do things like
that, and by default group sudo can run ALL.

Given that, I'm suggesting that the default configuration should also
pass through a few more environment variables *for group sudo*.
env_keep can be set on a per-group basis.

In my sudoers configuration, I set the following:

Defaults:%sudo env_keep += "http_proxy https_proxy ftp_proxy all_proxy no_proxy"

Anyone modifying the sudoers configuration such that "sudo" is not
root-equivalent (dropping the ability to run ALL) could easily drop that
line.  (They'd also want to be aware, though, that other mechanisms such
as polkit also assume that sudo is root-equivalent.)

Other environment variables I'd suggest adding to the whitelist:

# This allows running arbitrary commands, but so does ALL, and it means
# different sudoers have their choice of editor respected.
Defaults:%sudo env_keep += "EDITOR"

# Completely harmless preservation of a user preference.
Defaults:%sudo env_keep += "GREP_COLOR"

# While you shouldn't normally run git as root, you need to with etckeeper
Defaults:%sudo env_keep += "GIT_AUTHOR_* GIT_COMMITTER_*"

# Per-user preferences; root won't have sensible values for them.
Defaults:%sudo env_keep += "EMAIL DEBEMAIL DEBFULLNAME"

# "sudo scp" or "sudo rsync" should be able to use your SSH agent.
Defaults:%sudo env_keep += "SSH_AGENT_PID SSH_AUTH_SOCK"

# Ditto for GPG agent
Defaults:%sudo env_keep += "GPG_AGENT_INFO"

#620927#18
Date:
2021-02-24 20:19:41 UTC
From:
To:
tags #620927 confirmed
end

This is at least neat enough to have it as a suggestion in Debian's
default configuration. I have written this (commented out) in
/etc/sudoers for the time being.

Greetings
Marc

#620927#23
Date:
2021-02-24 20:19:41 UTC
From:
To:
tags #620927 confirmed
end

This is at least neat enough to have it as a suggestion in Debian's
default configuration. I have written this (commented out) in
/etc/sudoers for the time being.

Greetings
Marc

#620927#28
Date:
2021-02-24 20:52:40 UTC
From:
To:
* Marc Haber:

I have trouble imagining a scenario in which one wouldn't just tell the
user to configure the proxy specifically for APT (i.e.
Acquire::http::Proxy) instead. Let's just mark this "wontfix".

Cheers,
-Hilko

#620927#33
Date:
2021-02-24 21:04:40 UTC
From:
To:
tags #620927 wontfix
thanks

I myself have written elaborate mechanisms to find out which network I
am connected at the moment and setting the environment variables
appropriately. That effort would have to be repeated for the apt
configuration.

Agreed. I'll leave the comments inside sudoers since it's really a neat
idea and I am sure that not many users know that Defaults can be set
differently for different groups.

Greetings
Marc

#620927#38
Date:
2021-02-24 21:04:40 UTC
From:
To:
tags #620927 wontfix
thanks

I myself have written elaborate mechanisms to find out which network I
am connected at the moment and setting the environment variables
appropriately. That effort would have to be repeated for the apt
configuration.

Agreed. I'll leave the comments inside sudoers since it's really a neat
idea and I am sure that not many users know that Defaults can be set
differently for different groups.

Greetings
Marc

#620927#45
Date:
2024-05-05 18:58:33 UTC
From:
To:
I found this bug when in the same circumstance of /etc/environment proxy
settings not applying to sudo sessions.

I understand the rationale for "wontfix"-ing the previously suggested fix
of changing /etc/sudoers.

However, Ubuntu have been carrying a patch for the past 12 years which
addresses the issue in a different, potentially more acceptable way, and I
haven't been able to find any evidence in bug trackers of forwarding that
diff back to Debian being discussed, so I'm bringing it up here:

```
diff --git a/debian/etc/pam.d/sudo b/debian/etc/pam.d/sudo
index 96e8906a..7819ab18 100644
--- a/debian/etc/pam.d/sudo
+++ b/debian/etc/pam.d/sudo
@@ -3,6 +3,9 @@
 # Set up user limits from /etc/security/limits.conf.
 session    required   pam_limits.so

+session    required   pam_env.so readenv=1 user_readenv=0
+session    required   pam_env.so readenv=1 envfile=/etc/default/locale
user_readenv=0
+
 @include common-auth
 @include common-account
 @include common-session-noninteractive
diff --git a/debian/etc/pam.d/sudo-i b/debian/etc/pam.d/sudo-i
index d6385222..584b2d8e 100644
--- a/debian/etc/pam.d/sudo-i
+++ b/debian/etc/pam.d/sudo-i
@@ -3,6 +3,9 @@
 # Set up user limits from /etc/security/limits.conf.
 session    required   pam_limits.so

+session    required   pam_env.so readenv=1 user_readenv=0
+session    required   pam_env.so readenv=1 envfile=/etc/default/locale
user_readenv=0
+
 @include common-auth
 @include common-account
 @include common-session
```

Including pam_env.so in sudo's PAM configuration would apply system-wide
environment settings to sudo sessions, in a way which is generally
consistent with the existing Debian PAM configurations for cron, login,
sshd, and su.

The Ubuntu bug in which these changes were originally made 12 years ago was
https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/982684, and proxy
settings are cited as motivation there as well.

#620927#50
Date:
2026-06-01 05:25:05 UTC
From:
To:
Control: tags -1 confirmed wontfix
thanks

Please check whether the upload of sudo 1.9.17p2-6 fixes that issue for
you.

Greetings
Marc

#620927#53
Date:
2026-06-01 05:25:05 UTC
From:
To:
Control: tags -1 confirmed wontfix
thanks

Please check whether the upload of sudo 1.9.17p2-6 fixes that issue for
you.

Greetings
Marc