[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
finally.
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;
else
p++;
- if (strcmp(cmnd_base, p) != 0 || stat(path, &pst) == -1)
+ if (strcmp(cmnd_base, p) != 0)
return(FALSE);
+ 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