Before I describe the sudo problem I hit, I will tell you that the root cause of the problem is evident in the following output:
# mount
node mounted mounted over vfs date options
-------- --------------- --------------- ------ ------------ ---------------
/dev/hd4 / jfs2 Aug 14 12:00 rw,log=/dev/hd8
/dev/hd2 /usr jfs2 Aug 14 12:00 rw,log=/dev/hd8
/dev/hd9var /var jfs2 Aug 14 12:00 rw,log=/dev/hd8
/dev/hd3 /tmp jfs2 Aug 14 12:00 rw,log=/dev/hd8
/dev/hd11admin /admin jfs2 Aug 14 12:00 rw,log=/dev/hd8
/dev/mksysblv /export/mksysb jfs2 Aug 14 12:00 rw,log=/dev/loglv00
/dev/fslv00 /export/nim jfs2 Aug 14 12:00 rw,log=/dev/loglv00
/dev/hd1 /home jfs2 Aug 14 12:00 rw,log=/dev/hd8
/dev/hd10opt /opt jfs2 Aug 14 12:00 rw,log=/dev/hd8
/dev/swlv /software jfs2 Aug 14 12:00 rw,log=INLINE
/dev/fslv01 /tftpboot jfs2 Aug 14 12:00 rw,log=/dev/loglv00
/dev/livedump /var/adm/ras/livedump jfs2 Aug 14 12:00 rw,log=/dev/hd8
/dev/fixelv /fixes jfs2 Aug 14 12:00 rw,log=INLINE
/dev/lpmautolv /lpmauto jfs2 Aug 14 12:00 rw,log=INLINE
/dev/promonlv /promon jfs2 Aug 14 12:00 rw,log=INLINE
/aha /aha ahafs Aug 14 12:00 rw
The output above is from the mount command on an AIX host.
Can you see any problems that might impact sudo's ability to run?
No?
Problem Description:
A customer was attempting to use sudo to run some commands on an AIX host. Each time, sudo would fail with the following error message:
$ sudo -l
sudo: no tty present and no askpass program specified
The only information we had was that the host had been rebooted at some point in the last day or so.
We spent some time checking and verifying a bunch of things (specifically making sure that the /etc/sudoers file was intact and did not contain any bad entries) but none of them provided any real clues as to the root cause of the problem.
Problem Debugging and Investigation
We enabled debug for sudo. This involved creating an /etc/sudo.conf file with the following entries:
# vi sudo.conf
Debug sudo /var/log/sudo_debug.log all@debug
Debug sudoers.so /var/log/sudo_debug.log all@debug
Then, as the non-root user, we attempted to run sudo again. This generated some useful data in the /var/log/sudo_debug.log file. You'll notice we grep'ed for the string tty specifically, given that this was part of the sudo error message provided to us.
$ sudo -l
sudo: no tty present and no askpass program specified
# grep tty /var/log/sudo_debug.log
Aug 10 16:20:26 sudo[14352830] -> get_process_ttyname @ ./ttyname.c:417
Aug 10 16:20:26 sudo[14352830] unable to resolve tty via /proc/14352830/psinfo: A file or directory in the path name does not exist. @ get_process_ttyname() ./ttyname.c:442
Aug 10 16:20:26 sudo[14352830] <- get_process_ttyname @ ./ttyname.c:444 := (null)
Aug 10 16:20:26 sudo[14352830] -> sudo_get_ttysize_v1 @ ./ttysize.c:59
Aug 10 16:20:26 sudo[14352830] -> get_ttysize_ioctl @ ./ttysize.c:38
Aug 10 16:20:26 sudo[14352830] <- get_ttysize_ioctl @ ./ttysize.c:44 := 0
Aug 10 16:20:26 sudo[14352830] <- sudo_get_ttysize_v1 @ ./ttysize.c:75
Aug 10 16:20:26 sudo[14352830] searching for tty time stamp record @ timestamp_lock() ./timestamp.c:603
Aug 10 16:20:26 sudo[14352830] appending new tty time stamp record @ timestamp_lock() ./timestamp.c:611
Aug 10 16:20:26 sudo[14352830] tty time stamp position is 112 @ timestamp_lock() ./timestamp.c:617
Aug 10 16:20:26 sudo[14352830] -> tty_present @ ./tgetpass.c:360
Aug 10 16:20:26 sudo[14352830] <- tty_present @ ./tgetpass.c:361 := false
Aug 10 16:20:26 sudo[14352830] no tty present and no askpass program specified @ tgetpass() ./tgetpass.c:107
The following information was of great interest to us! It appeared to be that some information was "missing" from the /proc file system on the host?
# grep tty /var/log/sudo_debug.log | grep unable
Aug 10 16:20:26 sudo[14352830] unable to resolve tty via /proc/14352830/psinfo: A file or directory in the path name does not exist. @ get_process_ttyname() ./ttyname.c:442
Aug 18 11:19:59 sudo[21889328] unable to resolve tty via /proc/21889328/psinfo: A file or directory in the path name does not exist. @ get_process_ttyname() ./ttyname.c:442
Upon further investigation, we found that /proc did, in fact, appear to be completely empty!! This was not expected or normal on a modern AIX system.
# ls -ltr /proc
total 0
And, after running the mount command, we discovered that, yes, the /proc file system was NOT mounted!
# mount | grep proc
#
Resolution
Next, we attempted to mount /proc. But we couldn't, as it was not a known file system? Curious indeed.
# mount /proc
mount: 0506-334 /proc is not a known file system.
The /proc file system stanza was missing from /etc/filesystems. So, we added it back in and mounted the file system successfully.
# grep -p proc /etc/filesystems
# << No /proc entry found in /etc/filesystems!
# grep -p proc /etc/filesystems
/proc:
dev = /proc
vol = "/proc"
mount = true
check = false
free = false
vfs = procfs
# mount /proc
# mount | grep proc
/proc /proc procfs Aug 18 11:31 rw
# ls -ltr /proc | head -10
total 0
dr-xr-xr-x 8 root system 0 Aug 10 16:21 sys
-r--r--r-- 1 root system 91 Aug 10 16:21 version
dr-xr-xr-x 1 root system 0 Aug 10 16:21 0
dr-xr-xr-x 1 root system 0 Aug 10 16:21 1
dr-xr-xr-x 1 root system 0 Aug 10 16:21 260
dr-xr-xr-x 1 root system 0 Aug 10 16:21 65798
dr-xr-xr-x 1 root system 0 Aug 10 16:21 131336
dr-xr-xr-x 1 root system 0 Aug 10 16:21 196874
dr-xr-xr-x 1 root system 0 Aug 10 16:21 262412
As soon as /proc was mounted again, the non-root user could run sudo without any issues.
$ sudo -l
Password:
User cgibson may run the following commands on 750lpar4:
(ALL) /usr/sbin/slibclean
$
The /proc file system is different from other file systems. It does not reside on disk. The /proc file system resides in AIX memory and is referred to as a virtual file system. The files maintained in /proc represent the running processes on the system.
http://www-01.ibm.com/support/docview.wss?uid=isg3T1012015
https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.files/proc.htm