This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 521778 - sudo wildcard issue with long file names
sudo wildcard issue with long file names
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: sudo (Show other bugs)
5.4
All Linux
low Severity high
: rc
: ---
Assigned To: Daniel Kopeček
BaseOS QE
:
: 531369 551347 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-08 05:53 EDT by Marc Fournier
Modified: 2014-06-09 07:14 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-30 04:16:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Marc Fournier 2009-09-08 05:53:29 EDT
Description of problem:

When using wildcards on file names in /etc/sudoers, sudo fails when only one file matches and the filename is quite long.


Version-Release number of selected component (if applicable):

# sudo -V
Sudo version 1.6.9p17

Sudoers path: /etc/sudoers
Authentication methods: 'pam'
Syslog facility if syslog is being used for logging: authpriv
Syslog priority to use when user authenticates successfully: notice
Syslog priority to use when user authenticates unsuccessfully: alert
Ignore '.' in $PATH
Send mail if the user is not in sudoers
Use a separate timestamp for each user/tty combo
Lecture user the first time they run sudo
Require users to authenticate by default
Root may run sudo
Allow some information gathering to give useful error messages
Visudo will honor the EDITOR environment variable
Set the LOGNAME and USER environment variables
Length at which to wrap log file lines (0 for no wrap): 80
Authentication timestamp timeout: 5 minutes
Password prompt timeout: 5 minutes
Number of tries to enter a password: 3
Umask to use or 0777 to use user's: 022
Path to mail program: /usr/sbin/sendmail
Flags for mail program: -t
Address to send mail to: root
Subject line for mail messages: *** SECURITY information for %h ***
Incorrect password message: Sorry, try again.
Path to authentication timestamp dir: /var/run/sudo
Default password prompt: Password:
Default user to run commands as: root
Path to the editor for use by visudo: /bin/vi
When to require a password for 'list' pseudocommand: any
When to require a password for 'verify' pseudocommand: all
File containing dummy exec functions: /usr/libexec/sudo_noexec.so
Reset the environment to a default set of variables
Environment variables to check for sanity:
        TERM
        LINGUAS
        LC_*
        LANGUAGE
        LANG
        COLORTERM
Environment variables to remove:
        RUBYOPT
        RUBYLIB
        PYTHONINSPECT  
        PYTHONPATH
        PYTHONHOME
        TMPPREFIX
        ZDOTDIR
        READNULLCMD
        NULLCMD
        FPATH
        PERL5DB
        PERL5OPT
        PERL5LIB
        PERLLIB
        PERLIO_DEBUG   
        JAVA_TOOL_OPTIONS
        SHELLOPTS
        GLOBIGNORE
        PS4
        BASH_ENV
        ENV
        TERMCAP
        TERMPATH
        TERMINFO_DIRS  
        TERMINFO
        _RLD*
        LD_*
        PATH_LOCALE
        NLSPATH
        HOSTALIASES
        RES_OPTIONS
        LOCALDOMAIN
        CDPATH
        IFS
Environment variables to preserve:
        XAUTHORIZATION 
        XAUTHORITY
        TZ
        PS2
        PS1
        PATH
        MAIL
        LS_COLORS
        KRB5CCNAME
        HOSTNAME
        HOME
        DISPLAY
        COLORS


How reproducible:

easily


Steps to Reproduce:

root@hostname:/tmp/dir# cat /etc/sudoers 
Defaults !authenticate
user ALL=(root) /tmp/dir/test-*

user@hostname:~$ sudo -l
User user may run the following commands on this host:
    (root) /tmp/dir/test-*


# Long filename, only one file matching the wildcard: fails

root@hostname:/tmp/dir# ls -al
total 24
drwxr-xr-x 2 root root 4096 Sep  8 11:03 .
drwxrwxrwt 7 root root 4096 Sep  8 11:01 ..
-rwxr-xr-x 1 root root   22 Sep  8 11:00 test-abcdefghijklmnopqrs

user@hostname:~$ sudo /tmp/dir/test-abcdefghijklmnopqrs 
Sorry, user user is not allowed to execute '/tmp/dir/test-abcdefghijklmnopqrs' as root on hostname.


# More than one file matching the wildcard: works

root@hostname:/tmp/dir# ls -al
total 28
drwxr-xr-x 2 root root 4096 Sep  8 11:13 .
drwxrwxrwt 7 root root 4096 Sep  8 11:01 ..
-rwxr-xr-x 1 root root   22 Sep  8 11:00 test-abcdefghijklmnopqrs
-rw-r--r-- 1 root root    0 Sep  8 11:13 test-foobar

user@hostname:~$ sudo /tmp/dir/test-abcdefghijklmnopqrs
hello


# Filename one character shorter: works

root@hostname:/tmp/dir# ls -al
total 24
drwxr-xr-x 2 root root 4096 Sep  8 11:17 .
drwxrwxrwt 7 root root 4096 Sep  8 11:01 ..
-rwxr-xr-x 1 root root   22 Sep  8 11:00 test-abcdefghijklmnopqr

user@hostname:~$ sudo /tmp/dir/test-abcdefghijklmnopqr
hello



Actual results:

Sudo denies user to execute command.


Expected results:

Sudo should allow users to run commands with names as long as necessary.
Comment 1 Daniel Kopeček 2009-10-30 09:10:10 EDT
*** Bug 531369 has been marked as a duplicate of this bug. ***
Comment 4 Daniel Kopeček 2010-01-07 11:25:04 EST
*** Bug 551347 has been marked as a duplicate of this bug. ***
Comment 5 Vincent Danen 2010-01-25 13:38:14 EST
I'm seeing similar, but slightly different behaviour here.

% sudo -l
User vdanen may run the following commands on this host:
    (ALL) NOPASSWD: /tmp/dir/test-*
% ls -al /tmp/dir/
total 16
drwxr-xr-x  2 root root 4096 Jan 25 11:20 .
drwxrwxrwt 16 root root 4096 Jan 25 11:28 ..
-rwxr-xr-x  1 root root    7 Jan 25 11:11 test-abcdefghijklmnp
% sudo /tmp/dir/test-abcdefghijklmnp 
Password: 
Sorry, user vdanen is not allowed to execute '/tmp/dir/test-abcdefghijklmnp' as root on odvrhel5.annvix.ca.

sudo should not be asking for a password here, but it is.  I've also got a smaller file than that noted above, but I really have to shorten it to make it work:

% sudo /tmp/dir/test-abcdef      
root
% sudo /tmp/dir/test-abcdefg
Password: 
Sorry, user vdanen is not allowed to execute '/tmp/dir/test-abcdefg' as root on odvrhel5.annvix.ca.

I do _not_ have "Defaults !authenticate" set as the NOPASSWD specification would override that anyways (I did try with it set and it made no observable difference).

I can't account for the path length discrepancies either.

# rpm -q sudo
sudo-1.6.9p17-5.el5
# grep -v '^#' /etc/sudoers |grep -v Cmnd_Alias|uniq

Defaults    requiretty

Defaults    env_reset
Defaults    env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR \
                        LS_COLORS MAIL PS1 PS2 QTDIR USERNAME \
                        LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION \
                        LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC \
                        LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS \
                        _XKB_CHARSET XAUTHORITY"

root    ALL=(ALL)       ALL

vdanen ALL=(ALL) NOPASSWD: /tmp/dir/test-*
Comment 6 Andrew Elmore 2010-01-25 13:54:18 EST
As suggested by http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565223, the following patch resolved the issue for me:

--- sudo-1.6.9p17/parse.c.orig  2010-01-14 15:58:54.000000000 -0800
+++ sudo-1.6.9p17/parse.c       2010-01-14 16:12:40.000000000 -0800
@@ -316,9 +316,11 @@
                break;
            }
        }
-       globfree(&gl);
-       if (*ap == NULL)
+       if (*ap == NULL) {
+           globfree(&gl);
            return(FALSE);
+       }
+       globfree(&gl);
 
        if (!sudoers_args ||
            (!user_args && sudoers_args && !strcmp("\"\"", sudoers_args)) ||
Comment 7 Vincent Danen 2010-01-25 16:42:31 EST
(In reply to comment #5)
...
> I can't account for the path length discrepancies either.

FWIW, don't know if this makes a difference, but the path length is different on x86_64 vs x86:

% sudo /tmp/dir/test-abcdefghiklmnopqrst
Password:
Sorry, user vdanen is not allowed to execute '/tmp/dir/test-abcdefghiklmnopqrst' as root on odxrhel5.annvix.ca.
% sudo /tmp/dir/test-abcdefghiklmnopqrs
root
Comment 8 Chris Ward 2010-02-11 05:17:11 EST
~~ Attention Customers and Partners - RHEL 5.5 Beta is now available on RHN ~~

RHEL 5.5 Beta has been released! There should be a fix present in this 
release that addresses your request. Please test and report back results 
here, by March 3rd 2010 (2010-03-03) or sooner.

Upon successful verification of this request, post your results and update 
the Verified field in Bugzilla with the appropriate value.

If you encounter any issues while testing, please describe them and set 
this bug into NEED_INFO. If you encounter new defects or have additional 
patch(es) to request for inclusion, please clone this bug per each request
and escalate through your support representative.
Comment 9 Marc Fournier 2010-02-11 05:44:54 EST
> RHEL 5.5 Beta has been released! There should be a fix present in this 
> release that addresses your request. Please test and report back results 
> here, by March 3rd 2010 (2010-03-03) or sooner.

Works for me:

user@host1:~$ sudo /tmp/dir/test-abcdefghijklmnopqrs 
hello
user@host1:~$ rpm -q sudo
sudo-1.7.2p1-2.el5

user@host2:~$ sudo /tmp/dir/test-abcdefghijklmnopqrs 
Sorry, user user is not allowed to execute '/tmp/dir/test-abcdefghijklmnopqrs' as root on host2.
user@host2:~$ rpm -q sudo
sudo-1.6.9p17-5.el5

Many thanks folks !

> Upon successful verification of this request, post your results and update 
> the Verified field in Bugzilla with the appropriate value.

I can't see any "verified" field in my view of bugzilla. I set "needs
additional info from qa contact" instead. I suppose they have the privilege
to update this field.
Comment 12 errata-xmlrpc 2010-03-30 04:16:51 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2010-0212.html

Note You need to log in before you can comment on or make changes to this bug.