Your message dated Thu, 25 Feb 2021 10:37:39 +0000 (UTC) with message-id <[email protected]> and subject line Re: Bug#639323: sudoers unfortunate changes has caused the Debian Bug report #639323, regarding sudoers unfortunate changes to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 639323: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639323 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: sudo Version: 1.8.2-1 Severity: normal Apparently, there's a new directive in the default sudoers now: | Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" Without it, "sudo visudo" will fail. When asking Y to let dpkg overwrite the existing conffile on the system, people might lose root access to the entire machine. (No, I said N and manually run "sudo /usr/sbin/visudo" then merging it.) Like when env_reset became default (one of the first things I remove), this changes the default behaviour in an unsafe way, and as such should not (IMHO) be forced on the user on upgrade, i.e. upgrading existing systems should keep the older behaviour (while warning about it, probably). Also, visudo now asks | press return to edit /etc/sudoers.d/README: which, while cosmetic, will lead to much frustration and some confusion under the sysadmins. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.18-6-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/mksh Versions of packages sudo depends on: pn libc6 <none> (no description available) ii libpam-modules 1.1.3-1 Pluggable Authentication Modules f ii libpam0g 1.1.3-1 Pluggable Authentication Modules l sudo recommends no packages. sudo suggests no packages. -- Configuration Files: /etc/sudoers [Errno 13] Permission denied: u'/etc/sudoers' /etc/sudoers.d/README [Errno 13] Permission denied: u'/etc/sudoers.d/README' -- no debconf information
--- End Message ---
--- Begin Message ---Hi Marc, welcome to the sudo maintainer hat ;-) >On Fri, Aug 26, 2011 at 09:08:48AM +0000, Thorsten Glaser wrote: >> Bdale Garbee dixit: >> >Nothing is "forced on the user", the conffile handling is doing exactly >> >what is expected. If the admin chooses to not accept the update, the This could have been solved by adding the line to sudoers, waiting a release, and then removing it from the binary. Or, as Bill pointed out, done via /etc/sudoers.d/ instead. But this is ten years old now, thus probably irrelevant; better handling of configuration files as important as this one should still be in the back of the head of maintainers, but… ;-) >> >worst that happens is they have to fully qualify command paths until >> >they've patched up sudoers. Ah right, so there’s a workaround. [ conffile handling ] >Yes, but implementing a method like this is way beyond the amount of >work that a normal package is expected to invest. I'd hate to open this Indeed. There’s a five-digit bug against dpkg (IIRC) still open that requests to save the original versions of conffiles to the side, so that a later version can do the three-way diff; right now we don’t even have the base version of the conffile to diff against. I don’t know why this isn’t even done. We’d need this at least one release, ideally more, ahead of time before three-way merging becomes useful. But this isn’t something to do here. >Debian system. I'd also like to refrain from adding a ucf dependency >here. Yes, understandable. >> >> Also, visudo now asks >> >> | press return to edit /etc/sudoers.d/README: >This doesn't happen on current unstable with vi as the EDITOR. visudo on current sid doesn’t even offer to edit the files under /etc/sudoers.d/ any more at all, so yes, this is probably fixed. >> This is because /etc/sudoers contains >> | #includedir /etc/sudoers.d >> and /etc/sudoers.d/README is a file in that directory… > >Did visudo at one time actually invoke the Editor with /etc/sudoers AND >/etc/sudoers.d/* ? It doesn't seem to do this any more. It doesn’t seem to do this with either @includedir or #includedir any more. >Can we please close this bug report? I don't think that keeping it open Yup. Thanks for pinging, //mirabilos -- (gnutls can also be used, but if you are compiling lynx for your own use, there is no reason to consider using that package) -- Thomas E. Dickey on the Lynx mailing list, about OpenSSL
--- End Message ---
