[sudo-users] Assistance requested with recent upgrade from 1.6.8 to 1.7.2

[Michael Dunne]

Greetings, 

Thank you for the reply. I see this error in the logs:

 sudo: no tty present and no askpass program specified

When I run sudo - l as the user running the script I see:

sudo -l
Matching Defaults entries for repl on this host:
    !set_logname, syslog=auth, !umask

The current sudoers files does not contain the line you mentioned, but /etc/sudoers.rpmnew does contain it. I suppose that's the root of my question. Does that need to be explicitly stated in the sudoers file to take affect? Do I need to add a line to my current sudoers file stating Dafaults !reuiretty even though there's no mention of it currently?

Selinux is disabled. 

Thanks again for your assistance. 

Mike


On Sep 19, 2011, at 4:34 PM, Todd C. Miller wrote:

> On Mon, 19 Sep 2011 12:54:10 EDT, Mike Dunne wrote:
> 
>> I was recently handed a RHEL 5.7 system on which sudo was upgraded from versi
>> on 1.6.8 to 1.7.2 of sudo and the upgrade seems to be interfering with a rysn
>> c job responsible for backups. Within /etc/sudoers is the following line:
>> 
>> repl            ALL=NOPASSWD: REPLF,REPLB,LS,/usr/bin/rsync
>> 
>> REPLF is the name of the script and is defined earlier in the sudoers files a
>> s a cmnd_alias. When I manually run the script as the user I see permission d
>> enied errors on several directories. This same script runs on many other syst
>> ems here, but the only difference I can discern on the affected system is tha
>> t the version of sudo is newer. I know that many security features were added
>> in 1.7.0 and I was curious if perhaps a new default was added which might be
>> causing problems for us. 
> 
> If you check the logs files you should be able to tell whether the
> command is being run successfully via sudo.
> 
> One thing to check is that your sudoers file does not include a
> line like:
> 
>    Defaults requiretty
> 
> as this will prevent sudo from working from a cron job.
> 
> If the only issue you are seeing is the permission denied errors,
> you might check to see that SELinux is not interfering with things.
> 
> - todd