Hi,

sudo maintainer speaking here.

Currently, as far as I know, the installer installs sudo and puts the
initially created user in the sudo group if the user decided to not set
a password for root.

Would you consider, in this case, to drop a snippet (named zz_installer,
zz_sudogroup or zz_<created-user> - the zz_ prefix makes sure that this
snippet takes precedence, as the last match wins) into /etc/sudoers.d,
saying either
%sudo ALL=(ALL:ALL) ALL
or
<created-user> ALL=(ALL:ALL) ALL
?

Sudo will pick that up automatically.

That way, sudo could put the respective line
%sudo ALL=(ALL:ALL) ALL↲
in a comment in the default configuration file, making things a bit more
secure on fresh installation.

Thanks for your consideration.

Greetings
Marc

How will it make it more secure, it's simply moving a line around!

I'm not a D-I maintainer but I like the idea and that will make things
more obvious.

A system that had a root password set on installation will not have a
sudo rule for the (then-empty) sudo group at all.

OpenSUSE does it this way as well.

Greetings
Marc

Control: reassign -1 src:user-setup

I'd suggest a name containing "user-setup", the d-i component in charge
of configuring users and passwords in the installed system.

So keep adding sudo membership, I guess.

And stop adding sudo membership ?

How will you deal with the upgrade of existing installations which use
the default configuration file (which will be silently replaced IIUC)
and rely on sudo membership ? Uncomment the line or add a snippet in
postinst if the group is not empty ? Not sure a NEWS entry will be enough.

@sudo-team, this contains a suggestion of mine to get rid of the %sudo
ALL rule in /etc/sudoers proper, moving it to a dedicated file in
/etc/sudoers.d in a multi-step process ending in forky+1 at the
earliest. If this ends up in a sudo team discussion, please remove
#1136732 from the loop to avoid pestering the installer team.

Hi Pascal,

That should be user_setup. sudoers @includedir ignores files with dashes
in the file name.

Otherwise, that's fine with me. Please consider adding a comment like
"this was created by user-setup during system installation" so that
people can guess where it comes from. Normal users are probably not
familiar with the names of d-i components.

I would leave that decision to you. Both keeping group membership or
removing it has its advantages and dissadvantages:

Least change would be to use %sudo and keep adding membership, least
privilege would be to use the user name and not adding membership. A
possible midway would be to use the user name in the sudo rule and still
adding sudo membership.

If the Installer has taken their decision I will gladly put on my hat of
base-passwd co-maintainer and suggest a documentation change for the
sudo group.

My idea is to ship an /etc/sudoers.d/zz_sudo_group file while keeping
the %sudo ALL rule in /etc/sudoers, documenting the doubling of the
%sudo ALL rule both in comments in /etc/sudoers (which a user will not
see if they do not accept the package changes to the file) AND in
NEWS.Debian AND in the release notes for at least forky.

In forky+1 or forky+2 we could then remove the %sudo ALL rule from
/etc/sudoers proper, while keeping the change documented in the release
notes for all relevant releases.

But that is not yet decided at all, it's a fully new idea.

Greetings
Marc

IIUC, the final state is that the %sudo rule is in
/etc/sudoers.d/zz_sudo_group instead of /etc/sudoers. Then I have two
questions:

1) What is the point of the intermediate state with the %sudo rule in
both files ?
2) AFAICS the final state is functionally the same as the current state,
so what is the point of this transition ?

Not speaking for d-i maintainers, but I believe that the first step is
to define each stage of the transition of sudo package; then installer
components can be updated to accommodate to the changes, as usual.