[sudo-workers] sudo 1.6.8rc2 still has NFS/root bug

Harald Koenig koenig at science-computing.de
Wed Jul 21 14:01:41 EDT 2004

Hi sudoers !

recently there was a change in sudo being described as follows

        Major changes from version 1.6.7p5 to 1.6.8b1:
            * Sudo will now try to stat the command to be run as the user specified by the -u flag if the stat fails as root. Fixes an NFS issue.

but this patch missed at least one case, where the stat()
on the command argument still is executed as root.
below I've included my patch, which fixes at least our local
problem with the following comfiguration:

	sudo -u someuser /nfsserver/groupdir/groupprogram

groupdir and groupprogram don't have world access (both mode 750)
on NFS v2 server, someuser has group access to both dir and prog.

/etc/sudoers allows includes

	User_Alias   SOME = %group1,%group2
	SOME ALL=(someuser) NOPASSWD:/nfsserver/groupdir/groupprogram *

a more generic question/remark on that style of access tests
(first trying with PERM_ROOT, only on errors test with PERM_RUNAS):

IMHO (if I'm not totally wrong) this desgin is _wrong_! 
all access tests to the command path should be done 
_always_and_only_ with PERM_RUNAS!

if runas_pw->pw_uid is 0 (root), nothing changes, and
it it's non-zero/root, then there is no reason at all
to run those tests with PERM_ROOT first, no matter if the
command path is on a local fs or on NFS etc.

the following scenario can give false-positive (OK) results
for those stat() calls, which is not what you want.  otherwise,
you could just remove those stat() calls and let the exec() fail 

if you're running "sudo -u user1 /nfsv2/user2dir/tool" 
e.g. on a Linux NFS v2 client (kernel nfs) without "sync"
mount option (which usually is the default for performace
reasons), then the allowed user access from user2 to his
directory and tool (both mode 700) get cached in the 
kernel inode cache, and if you run stat() as root
on this path, then you'll get "SUCCESS"  returned
for the test with PERM_ROOT, so you'll never see the
failure of that test with PERM_RUNAS which you'd expect
which which you'd like to handle and report to the user !

exactly this happend to our setup above for quite a 
number of different Linux boxes (all 2.4.x kernel)
and other unixes with HP-UX 10.20 NFS v2 server (don't ask!).
the script with sudo with no world access to directory/program
worked well for months being called thousand times from
many users on different workstations before the very first
and very rare failure occured, when the user got asked
for as password because the PERM_ROOT test for command path
accidentially failed (about once a week only or less!).

this all would not have happend if the design of sudo
would not do any tests with PERM_ROOT on the command path 
at all -- it's just wrong and usually it doesn't matter
because runas_pw->pw_uid is 0 for 99.999% of all cases ?!?


--- sudo-1.6.8rc2/parse.c.orig	Wed Jul 21 18:51:37 2004
+++ sudo-1.6.8rc2/parse.c	Wed Jul 21 18:49:04 2004
@@ -319,8 +319,20 @@
 		p = path;
-	    if (strcmp(cmnd_base, p) != 0 || stat(path, &pst) == -1)
+	    if (strcmp(cmnd_base, p) != 0)
+	    if (stat(path, &pst) == -1) {
+	        if (runas_pw->pw_uid != 0) {
+		    int error;
+		    set_perms(PERM_RUNAS);
+		    error = stat(cmnd, &pst);
+		    set_perms(PERM_ROOT);
+		    if (error == -1)
+		        return(FALSE);
+		}
+		else 
+		    return(FALSE);
+	    }
 	     * Return true if inode/device matches AND

Harald Koenig
"I hope to die                                      ___       _____
before I *have* to use Microsoft Word.",           0--,|    /OOOOOOO\
Donald E. Knuth, 02-Oct-2001 in Tuebingen.        <_/  /  /OOOOOOOOOOO\
                                                    \  \/OOOOOOOOOOOOOOO\
                                                      \ OOOOOOOOOOOOOOOOO|//
Harald Koenig                                          \/\/\/\/\/\/\/\/\/
science+computing ag                                    //  /     \\  \
koenig at science-computing.de                            ^^^^^       ^^^^^

More information about the sudo-workers mailing list