[sudo-users] Odd sudo behavior: some users can, others cannot

Axley, Jason jason.axley at wamu.net
Thu Apr 27 17:26:29 EDT 2006

Posting to the sudo-users list as well, but we're having a very strange problem with our sudo configuration on Solaris where sudo is not being consistent about who is allowed and who is not.

We have a rule like the following that works for some users, but not for others:

Host_Alias      UATAPP = appu711, appu712, appu713, appu714
Runas_Alias     WLOGIC = weblogic, blah

%somegroup UATAPP = (WLOGIC) /opt/weblogic/bin/script.sh

Both users are members of somegroup and are running this on the box appu711:

sudo -u weblogic /opt/weblogic/bin/script.sh


sudo -l

    (weblogic, blah) /opt/weblogic/bin/script.sh

Shows that he is authorized to run the command, but when he tries to run the command:

UserA is not allowed to run sudo on appu711.  This incident will be reported.

Syslog shows:

Apr 27 15:31:36 appu711 sudo: [ID 702911 auth.alert]  UserA : user NOT authorized on host ; TTY=pts/6 ; PWD=/home/UserA ; USER=weblogic ; COMMAND=/opt/weblogic/bin/script.sh

However, for UserB, the user can execute the same command just fine:

Apr 27 15:31:28 appu711 sudo: [ID 702911 auth.notice]  UserB : TTY=pts/2 ; PWD=/home/UserB ; USER=weblogic ; COMMAND=/opt/weblogic/bin/script.sh

The only functional difference between the accounts is the group membership.  UserB is a member of additional groups than UserA.

In the code, parse.c, it looks like this is the code that sets the flag to trigger the error UserA sees:

    if (pwflag)
        pwcheck = (pwflag == -1) ? never : sudo_defs_table[pwflag].sd_un.tuple;
        pwcheck = 0;

     * Assume the worst.  If the stack is empty the user was
     * not mentioned at all.
    if (def_authenticate)
        error = VALIDATE_NOT_OK;
        error = VALIDATE_NOT_OK | FLAG_NOPASS;
    if (pwcheck) {
        SET(error, FLAG_NO_CHECK);
    } else {
        SET(error, FLAG_NO_HOST);       /* THIS LINE */
        if (!top)
            SET(error, FLAG_NO_USER);

Why would FLAG_NO_HOST be set for some users, but not others?  A parser bug in sudo?  A bug in the sudoers config file?  I can't see a reason that sudo -l would list a command correctly that a user should be able to execute and then deny them execution of that command--unless there is some sort of bug lingering here.

I can provide a larger section of the sudoers file with additional rules for these group members if you like.  I'll have to sanitize it first.



Jason Axley, CISSP
Sr. Security Engineer

More information about the sudo-users mailing list