sudo's postinst uses prompting, which is not allowed by section 3.9.1 of
policy. Given the probability of it actually being triggered, I rated this
minor (but it could be considered RC by nitpickers).

Also, I spotted other very minors bugs in this postinst:
 * I do not understand why /etc/sudoers is not simply a conffile,
   especially now that /etc/sudoers.d is supported.
 * /etc/sudoers is not cleaned on purge (it should, and would if it were a
   conffile)
 * the stanza with update-rc.d looks like it will not change anything
 * it does not stop in cases of errors

Reading the various scripts, I suspect the postinst could be written in
shell very simply:
#! /bin/sh
set -e
# make sure sudoers has the correct permissions and owner/group
chown root:root /etc/sudoers
chmod 440 /etc/sudoers

# For the following, I am not sure this is not a bug
# This surely does nothing at all!
update-rc.d -f sudo remove >/dev/null 2>&1 || true
update-rc.d sudo start 75 2 3 4 5 . >/dev/null || true

if [ "$1" = "configure" ]; then
        addgroup --quiet --system sudo || {
          # addgroup failed. Why?
          if ! getent group sudo >/dev/null ; then
             echo "Could not create system group sudo." >&2
             exit 1
          fi
          # well, the group is there, so just ignore the error
fi

On Wed, 17 Mar 2010 23:57:09 +0100, Jean-Christophe Dubacq <jcdubacq1@free.fr> wrote:

Thanks for the questions on IRC yesterday, and for this but report.
After some sleep and re-reading some of my changelog entries, this isn't
quite as simple as it seemed yesterday.

History and inertia, mostly.  The current processing actually pre-dates
clean conffile handling by dpkg, and largely pre-dates my taking over
the sudo package from Michael Meskes in 1996.

The one reason I can remember this morning to not just replace the
current handling without further thought is that removing sudoers on
purge can cause problems for people moving systems between sudo and
sudo-ldap.  Leaving the sudoers file in place on a purge was deemed the
least evil choice the last time I reviewed this functionality in April
of 2007 in response to #401366.

In most cases, it won't.  The code is there because a very old version
of sudo created an inappropriate set of links for the startup script
fragment.  This stanza caused any lingering instances of that mess to be
cleaned up.  It has been enough years that we can probably remove that
code with no penalty... but it certainly does no harm.

Bdale

However, since sudo and sudo-ldap conflicts with each other, if the rm
is made on purge, it is not purged because of conflicts (only
deinstalled). You could also have a sudo-common, which owns the files.

And in fact, I think the best solution would be to do what some
databases do, and would correspond to what you aim to do with the other
files: namely, preventing losing root access for people using sudo as
sole root access. Ask a question with debconf about whether /etc/sudoers
should be deleted on purge, and if it is "yes", then delete. People
having a root password will gladly say it should be cleaned, and people
going to some length to have no root password will simply say no.

But well, it is more work.

In fact, what I meant is: "It won't do anything because the man page for
update-rc.d says:
~When  invoked  with the remove option, update-rc.d removes any links in
~the /etc/rcrunlevel.d directories to the script /etc/init.d/name.   The
~script  must have been deleted already.  If the script is still present
~then update-rc.d aborts with an error message.
which means that in the postinst (where the script is always present),
it will never do anything.

Anyway, nice having some explanations. I feel more knowledgeable tonight.

Sincerly,

Indeed, and adds a debconf dependency where none currently exists.  I'll
have to think about that.

Oh, interesting.  I'm inclined to believe that means the update-rc.d
behavior has changed since I added that code (long ago), because I know
it worked as expected "back then".  This certainly makes it clear that
it's time for that code to just go away...  Thanks.

Bdale

Hi,

given that the update-rc.d stanza discussed in this report having been
removed at some point in the past and that we have #678925 also
reporting the non-removal of /etc/sudoers on purge, can we close this?

I understand that this is a very old issue and do not expect an answer,
I will though close this bug report by the end of March 2022 if no
answer is given.

Greetings
Marc

Hi,

given that the update-rc.d stanza discussed in this report having been
removed at some point in the past and that we have #678925 also
reporting the non-removal of /etc/sudoers on purge, can we close this?

I understand that this is a very old issue and do not expect an answer,
I will though close this bug report by the end of March 2022 if no
answer is given.

Greetings
Marc

Control: outlook -1 close by 2022-03-31

Control: outlook -1 close by 2022-03-31