Bug 305 - sudo to root gets "can't access" error
sudo to root gets "can't access" error
Status: RESOLVED INVALID
Product: Sudo
Classification: Unclassified
Component: Sudo
1.6.9
All All
: normal normal
Assigned To: Todd C. Miller
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-10 11:12 MDT by Larry Bamford
Modified: 2008-10-10 11:22 MDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Larry Bamford 2008-10-10 11:12:29 MDT
FACTS
The following error occurs if /nsr/logs has root:root:700 mode:
$ sudo chmod 644 /nsr/logs/*
chmod: can't access /nsr/logs/*
$ 

I expected the files in /nsr/logs to get 644 mode instead.  They didn't.

sudoers file includes: 
larry           cephas=NOPASSWD:/bin/chmod 644 /nsr/logs/*

sudo -l reports:
    (root) NOPASSWD: /bin/chmod 644 /nsr/logs/*

If root runs chmod 755 /nsr/logs then the sudo command works as expected.

CONJECTURE
My theory is the wildcard interpretation occurs before the privilege escalation.  The * then is passed to the privileged chmod command as a literal * character.  As evidence, root gets the same result when fed an escaped * character:

# chmod 644 /nsr/logs/\*
chmod: can't access /nsr/logs/*
# 

Shouldn't the command line be interpreted in the privileged state?

Same happens on Linux, Solaris, and HP-UX with sudo versions as far back as 1.6.7p5 and as late as 1.6.9p17.
Comment 1 Todd C. Miller 2008-10-10 11:22:45 MDT
The problem is that wild card expansion is performed by the shell, well before sudo is even executed. Thus the expansion is done with your user credentials and not root's.

Unfortunately, this means that to get the expansion done as root you'll need to wrap a shell around it.  E.g.

$ sudo sh -c "chmod 644 /nsr/logs/*"

Or, better yet, create a shell script that sets the modes you need and give the user sudo access to that.