Changing file permissions works as root but not as sudo

Question

I have a really strange problem. I have a few files in a large directory that I want to make readable by everyone. So I try this:

sudo find readme* -not -perm -o+r -exec chmod +r {} \;

and get this:

sudo: unable to execute /usr/bin/find: Success

I don't know why it says Success, because the permissions were not changed. I verified by typing this:

find readme* -not -perm -o+r -exec ls -l {} \;

and get something like

-rw------- 1 root root 536871076 Nov 22 14:06 readme_20101122200429
-rw------- 1 root root 536871892 Nov 22 14:08 readme_20101122200642
-rw------- 1 root root 293458128 Nov 22 14:10 readme_20101122200859

as a last resort, I tried:

sudo chmod +r *

and got:

sudo: unable to execute /bin/chmod: Success

and again Success really means fail. So, I gave up and logged in as root and tried:

find readme* -not -perm -o+r -exec chmod +r {} \;

This time it worked. Why?

EDIT: /etc/sudoers looks like:

## Allow root to run any commands anywhere
root    ALL=(ALL)       ALL

##Me
user1   ALL=(ALL)       ALL

Answer 1

I don't know on wich version of find you are using. But, usually the first argument is the directory where to find, and if you want to filter on some filenames you have to use the -name argument. My guess will be

sudo find . -name 'readme*' -not -perm -o+r -exec chmod +r {} \;

Do not forget to single-quote the file name pattern. If you don't, the * will be evaluated by the shell and not passed directly as an argument. This may explain the strange behaviour. Because in this case, probably the shell try to pass every filename matching readme* as arguments to sudo.

Answer 2

I think you should use:

sudo sh -c 'find readme* -not -perm -o+r -exec chmod +r {} \;'

This causes sudo to run the shell which then interprets the argument to -c as a shell script. Using single-quotes around it is simplest - unless there are single quotes in the command to be executed. In that case, each single quote in the command is replaced by four characters - '\'': quote, backslash, quote, quote.

However, in the context, I'd not want to guarantee that you wouldn't get:

sudo: unable to execute /bin/sh: Success

The odd error probably means that an exec*() family function call returned, but the value left in errno was zero. That shouldn't happen - but apparently did. What happens with:

sudo /bin/ls      # Or /usr/bin/ls if that's correct for your machine

When did you last check on the sudo installation? When did you last reboot? It looks like there is something screwball in the way sudo is (mis)handling the commands for you.

Is the directory you're working in NFS mounted? Root typically has rather minimal privileges in such directories. But the error should be of the EPERM (No permission) variety, not the 'success when failed' variety.