Bug 498

Are you using the AIX 5.3 binary package or did you build sudo from source?  If from source, what configure options did you specify?

Hi,

Did you ever get this working - I am having the same issue on our VIO servers

$ sudo -V
Sudo version 1.8.3p1
sudo: unable to change to sudoers gid: Operation not permitted.
sudo: unable to initialize policy plugin

[padmin/]  oslevel -s
6100-04-06-1034
[padmin/]  ioslevel
2.2.0.10-FP-24

thanks,
Ian

Can you try ftp://ftp.sudo.ws/pub/sudo/beta/sudo-1.8.4rc2.tar.gz and see if you still have the same problem?  I've been unable to reproduce the issue.

Hi Todd,

same error still

$ sudo -V
Sudo version 1.8.4rc2
sudo: setreuid(ROOT_UID, -1): Operation not permitted.

This is only occuring on the VIO servers, plain AIX builds are OK. I'm not sure what the difference is

ian

Error message slightly different but appears to be the same problem

Please try ftp://ftp.sudo.ws/pub/millert/sudo/sudo-1.8.4-aix.tar.gz and see if that works for you.  I've added some AIX specific code in the uid setting since it seems to have subtly different behavior.

thanks Todd, different message again now...

$ sudo -V
Sudo version 1.8.4-aix
sudo: setuidx(ID_EFFECTIVE|ID_REAL|ID_SAVED, ROOT_UID): Operation not permitted.

cheers.
ian

It seems that the security policy on AIX VIO is different from a normal AIX server. There is some info http://publib.boulder.ibm.com/infocenter/powersys/v3r1m5/index.jsp?topic=/iphb1/iphb1security.htmat 

You can use the viosecure command to view or change change the security level.  I'm not familiar with AIX Virtual I/O servers but hopefully this will point you in the right direction.

Proper url http://publib.boulder.ibm.com/infocenter/powersys/v3r1m5/index.jsp?topic=/iphb1/iphb1security.htm:

Thanks Todd, the viosecure command is basically just a wrapper to configure the underlying AIX O/S. I've looked through that documentation but can't find anything relevant. Will keep looking...cheers

I asked this question on the sudo-users list and it sounds like you have run afoul of the new-style RBAC in AIX 6 and above.

Several people responded that you can use the oem_setup_env command as user padmin to change your uid to 0 (root).

I've done some digging of my own and it appears that sudo may need an entry in /etc/security/privcmds similar to the one for /usr/bin/su, and then loaded via the setkst command.  At the very least, sudo needs the PV_DAC_UID and PV_DAC_GID privileges.

Hey Todd,

The following seems to fix it - look OK to you?

padmin@sbduxv18[padmin/]  tail -4 /etc/security/privcmds
/opt/freeware/bin/sudo:
        accessauths = ALLOW_ALL
        innateprivs = PV_DAC_UID,PV_DAC_GID
        secflags = FSF_EPS

thanks,

ian

That looks fine.  I wasn't sure whether PV_DAC_UID,PV_DAC_GID would be sufficient by themselves but if it works then great.

excellent - thanks

Marking as fixed.  I've added an entry to doc/TROUBLESHOOTING that should help if someone else runs into this problem.

PV_DAC_UID,PV_DAC_GID don't seem to be enough permissions. I haven't had time to look into it but see example below....

$ sudo find /home/testdir
/home/testdir
find: 0652-081 cannot change directory to </home/testdir>:
  : The file access permissions do not allow the specified action.
$ ^D
padmin@sbduxv18[home/]  ls -ld /home/testdir
drwx------    2 700      700             256 Feb 28 16:15 /home/testdir

Try the following expanded entry in /etc/security/privcmds.  It is probably the missing PV_DAC bits that are causing that problem.

/opt/freeware/bin/sudo:
            accessauths = ALLOW_ALL
            innateprivs = PV_DAC_GID,PV_DAC_O,PV_DAC_R,PV_DAC_UID,PV_DAC_W,PV_DA
C_X,PV_FS_CHOWN,PV_PROC_ENV,PV_PROC_PRIO,PV_PROC_RAC
            secflags = FSF_EPS

Still the same unfortunately....

padmin@sbduxv18[padmin/]  tail -10 /etc/security/privcmds
/opt/freeware/bin/sudo:
        accessauths = ALLOW_ALL
        innateprivs = PV_DAC_GID,PV_DAC_O,PV_DAC_R,PV_DAC_UID,PV_DAC_W,PV_DAC_X,PV_FS_CHOWN,PV_PROC_ENV,PV_PROC_PRIO,PV_PROC_RAC
        secflags = FSF_EPS

/usr/bin/sudo:
        accessauths = ALLOW_ALL
        innateprivs = PV_DAC_GID,PV_DAC_O,PV_DAC_R,PV_DAC_UID,PV_DAC_W,PV_DAC_X,PV_FS_CHOWN,PV_PROC_ENV,PV_PROC_PRIO,PV_PROC_RAC
        secflags = FSF_EPS

padmin@sbduxv18[padmin/]  type sudo
sudo is /usr/bin/sudo
padmin@sbduxv18[padmin/]  ls -l /usr/bin/sudo
lrwxrwxrwx    1 root     system           27 Feb 22 21:01 /usr/bin/sudo -> ../../opt/freeware/bin/sudo
padmin@sbduxv18[padmin/]  su - nagios
3004-614 Unable to change directory to "/home/nagios".
        You are in "/home/guest" instead.
$ sudo find /home/testdir
/home/testdir
find: 0652-081 cannot change directory to </home/testdir>:
  : The file access permissions do not allow the specified action.
$ ls -ld /home/testdir  
drwx------    2 700      700             256 Feb 28 16:15 /home/testdir

You could try adding PV_SU_EMUL or PV_SU_ROOT.  Other than that, I don't know what else to suggest.  If you are able to grant me access to the system in question I may be able to debug the problem further.

I've added PV_ROOT_,PV_SU_ which from what I can tell should give full access but it still doesn't work. It works OK for directories with restrictive permissions but not for ones with no owner/group. If you can set up a webex session from your end I can give you access?

$ sudo find /home/test*
/home/test
/home/test/test
/home/testdir
find: 0652-081 cannot change directory to </home/testdir>:
  : The file access permissions do not allow the specified action.

$ ls -ld /home/test*
drwx------    2 root     staff           256 Apr 11 16:32 /home/test
drwx------    2 700      700             256 Feb 28 16:15 /home/testdir