Package: sudo
Version: 1.8.2-1
Severity: normal

The latest version closes Bug#85123 and Bug#85917.  However the
resulting change in behavior of secure_path is significant and needs a
NEWS entry.  Most users with sudo installed will have a modified
/etc/sudoers file and will need to manually merge a secure_path entry
into the file.  If not then it will break anyone who already has a
customized /etc/sudoers file, fails to notice this change, and doesn't
merge in the new package maintainer's version when upgrading, and does
not include sbin paths in their user PATH.  At that point they will
have two problems.

1. If their user path did not include the /usr/sbin:/sbin directories
   then the sudo path won't either and commands such as apt will fail
   to find their utilities.  For example the following errors to make
   this found by search engines:
     dpkg: warning: 'ldconfig' not found in PATH or not executable.
     dpkg: warning: 'start-stop-daemon' not found in PATH or not executable.
     dpkg: error: 2 expected programs not found in PATH or not executable.
     Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and 
/sbin.

2. If the user path is insecure then they will now have an insecure
   root path.  Arguably this is under their control.  But the change
   should be more visible than it is now.

Let me suggest the following NEWS entry, or something similar:

sudo (1.8.2-1) unstable; urgency=low

  The default setting for secure_path has been changed.  The new
  setting is off by default.  Previously it was not possible to unset
  secure_path and the compiled in value was used by default.  It was
  only possible to change the value of it.  See Bug#85123 and
  Bug#85917.  Now if the administrator desires to have it unset they
  need only to avoid setting it.  To preserve the previous behavior in
  new installs a new setting of secure_path with a default path has
  been added to /etc/sudoers.  But that only handles new
  installations.  If you have a customized conffile, most do, and you
  wish to preserve the previous behavior, most will, then action is
  needed on your part.  You will need to merge entries of these files
  to include a secure_path setting into your /etc/sudoers file.

Alternatively the sudo package could include a new conffile file in
the package /etc/sudoers.d/00-secure_path or some such that includes
the new secure_path setting.  Being a new file it would be installed
by default without dialog and become available.  Being a conffile if
an admin desired it to not be set then they could edit that file and
unset it.  I don't like the proliferation of packaged conffiles in
that directory but that might be a solution.  But in that case a new
NEWS entry would be needed.  :-)

Bob



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to