Originally posted by: PhillR

Hi,

I have found that when updating to sudo 1.8.20p2-4 (or any 1.8.X) that the /etc/sudoers file is being replaced with a default sudoers file from the RPM.  This has caused us some issues when it's found that something that is relient on our sudo configuration is broken due to this.  The update process also doesn't save the sudoers file that it's overwritten so that there is an easy fix, we've usually had to restore it from our backups.  Could you please take a look at this?

Thanks,

Phill.

Originally posted by: AyappanP

This should not be the case. I just checked by installing the rpm and it is not overwriting the exisitng /etc/sudoers file. 

And also checked the SPEC file. We are using "%config(noreplace)" for /etc/sudoers so that at any scenario it won't replace the existing file.

Could you please re-check ?

Originally posted by: PhillR

This has certinaly happened, we haven't had an update to sudo 1.8 that hasn't done it yet.  It's a stange one then.

Originally posted by: PhillR

The RPMs that we've been upgrading from have been:-

root@XXXXXX:/>rpm -qi sudo-1.7.0-1
Name        : sudo                         Relocations: /opt/freeware
Version     : 1.7.0                             Vendor: (none)
Release     : 1                             Build Date: Tue 14 Apr 17:14:19 2009
Install date: Thu 31 Aug 10:16:36 2017      Build Host: toolbox2.coopibm.frec.bull.fr
Group       : Applications/System           Source RPM: sudo-1.7.0-1.src.rpm
Size        : 538384                           License: IBM_ILA
URL         : http://www.courtesan.com/sudo
Summary     : Allows restricted root access for specified users.
Description :
Sudo (superuser do) allows a system administrator to give certain users (or
groups of users) the ability to run some (or all) commands as root while
logging all commands and arguments. Sudo operates on a per-command basis.  It
is not a replacement for the shell.  Features include: the ability to restrict
what commands a user may run on a per-host basis, copious logging of each
command (providing a clear audit trail of who did what), a configurable timeout
of the sudo command, and the ability to use the same configuration file
(sudoers) on many different machines.
 

YYYYYYY:/ # rpm -qi sudo-1.7.0-1
Name        : sudo                         Relocations: (not relocateable)
Version     : 1.7.0                             Vendor: (none)
Release     : 1                             Build Date: Mon 22 Dec 16:29:32 2008
Install date: Mon 21 Feb 09:00:08 2011      Build Host: aix51.perzl.org
Group       : Applications/System           Source RPM: sudo-1.7.0-1.src.rpm
Size        : 714684                           License: BSD
URL         : http://www.courtesan.com/sudo/
Summary     : Allows restricted root access for specified users
Description :
Sudo (superuser do) allows a system administrator to give certain
users (or groups of users) the ability to run some (or all) commands
as root while logging all commands and arguments. Sudo operates on a
per-command basis.  It is not a replacement for the shell.  Features
include: the ability to restrict what commands a user may run on a
per-host basis, copious logging of each command (providing a clear
audit trail of who did what), a configurable timeout of the sudo
command, and the ability to use the same configuration file (sudoers)
on many different machines.

We also have an older internally packaged sudo 1.6 RPM on some LPARs

I wonder if this is part of the issue and that we might just have to go through the updates with a backup & restore of /etc/sudoers ?  Once we have updated to 1.8, further updates haven't caused the issue.

Originally posted by: PhillR

Would it be possible to have the sudo 1.8 RPM make a copy of /etc/sudoers to /etc/sudoers.rpmsave?  I've seen Linux distros do this when an updated rpm needs to make changes to a config file.

Originally posted by: Timofey_D

From my experience the best option here is to use /etc/sudoers.d for sudo config files and leave /etc/sudoers in its default condition.

Originally posted by: PhillR

That would be ok if we didn't have 1000+ LPARs with existing configurations that we don't really want to have overwritten.  It would be quite an amount of work to reconfigure this.  Also I do not see that an update overwriting an existing configuration in this manner is a desirable behaviour.

Originally posted by: Timofey_D

Regarding behavior I fully agree.

After experiencing the same thing with one of sudo 1.6 updates I've reworked our sudo config layout to sudoers.d since it was the only fail-proof option.

Originally posted by: AyappanP

I just did a small testing to verify the problem. But it is working for me. The /etc/sudoers is not overwritten.

Downloaded the same sudo-1.7.0-1 rpm from perzl site and installed it. Edited the /etc/sudoers and then installed AIX Toolbox sudo-1.8.20p2-4 rpm. It actually created a new file .rpmnew and the older sudoers file is not touched.

# rpm -ivh sudo-1.7.0-1.aix5.1.ppc.rpm
Preparing...                ########################################### [100%]
   1:sudo                   ########################################### [100%]

(0) root @ aixoss-automation-3: 6.1.0.0: /
# rpm -qi sudo
Name        : sudo
Version     : 1.7.0
Release     : 1
Architecture: ppc
Install Date: Wed Jan 24 20:40:18 IST 2018
Group       : Applications/System
Size        : 714684
License     : BSD
Signature   : (none)
Source RPM  : sudo-1.7.0-1.src.rpm
Build Date  : Mon Dec 22 21:59:32 IST 2008
Build Host  : aix51.perzl.org
Relocations : (not relocatable)
URL         : http://www.courtesan.com/sudo/
Summary     : Allows restricted root access for specified users
Description :
Sudo (superuser do) allows a system administrator to give certain
users (or groups of users) the ability to run some (or all) commands
as root while logging all commands and arguments. Sudo operates on a
per-command basis.  It is not a replacement for the shell.  Features
include: the ability to restrict what commands a user may run on a
per-host basis, copious logging of each command (providing a clear
audit trail of who did what), a configurable timeout of the sudo
command, and the ability to use the same configuration file (sudoers)
on many different machines.

(0) root @ aixoss-automation-3: 6.1.0.0: /
# echo Hello >> /etc/sudoers

(0) root @ aixoss-automation-3: 6.1.0.0: /
# rpm -Uvh sudo-1.8.20p2-4.aix6.1.ppc.rpm
Preparing...                ########################################### [100%]
   1:sudo                   warning: /etc/sudoers created as /etc/sudoers.rpmnew
########################################### [100%]

Originally posted by: AyappanP

Checked in RPM 3.0.5 version also ( the above is done in RPM 4.9.1.3 ). Not sure what is causing the issue in your case.

Originally posted by: PhillR

The most recent server I've had this happen with is 7100-05-01-1731 with

# lslpp -l |grep rpm
  rpm.rte                   4.13.0.1  COMMITTED  RPM Package Manager
  rpm.rte                   4.13.0.1  COMMITTED  RPM Package Manager

Originally posted by: PhillR

I'll keep an eye out on any further updates that we do to see what occurs.  Strange that you haven't been able to reproduce it as it's been fairly consistent for us.

Originally posted by: AyappanP

Yeah sure. Just checked in RPM 4.13.0.1. No issue there as well.

Let's check this ->  Are you upgrading the RPM itself and then updating the sudo rpm ? 

Originally posted by: PhillR

RPM is upgraded as part of the update to 7100-05-01-1731, after the update from 7100-04-01 -> 7100-05-01-1731, sudo along with all other RPMs were updated using "yum update"

Originally posted by: LoriB

I have experienced this as well, after the first time it happened I incorporated a step to save my existing sudoers file so I can copy it back into place after the update.  It does appear that the current version 1.8.20p2-4  is creating an sudoers.rpmsave file with the contents of the existing file.  I still always make a copy before using yum to update sudo.

Originally posted by: PhillR

Yes, I've done the same.