#4213 sudo: user.name : command not allowed


Issue started after upgrading a full-working server from CentOS 6.3 to CentOS 6.4 (both 32 and 64bit).
User's authorization and authentication are on MS Active Directory.

SSH and sudo work fine but is not possible to get them access on webmin.
Seems to be a problem with user groups from AD: To let my user to log in again, I need to explicit my username in /etc/sudoers.

Working untill CentOS 6.3:

Working on CentOS 6.4:

Only webmin seems to be affected after distro's upgrade.


<< < 1 2 (Page 2 of 2)
  • frakka

    frakka - 2013-05-15

    Upgrade to webmin 1.63 don't gives any changes. The problem persists.

  • kunzol

    kunzol - 2016-02-15

    I had the same problem.
    I use sssd-LDAP authentication on the host via pam.
    Somehow sudo needs to scan all users/groups, which is by default not possible.
    First I had to configure "enumerate=true" in /etc/sssd/sssd.conf.
    Second I had to configure the "sizeLimit" on the OpenLDAP server, that all users/groups can be queried at once.

    I haven't found out yet, why sudo needs this in this case.

    By the way, the same "sudo -l -S" command on the commandline works with "enumerate=false".

    Another small remark about "strace". The solution is to trace the webmin server with "strace -f" and grep the needed process from the tracefile.

  • Jamie Cameron

    Jamie Cameron - 2016-02-16

    How did you pass the enumerate=false setting?

  • kunzol

    kunzol - 2016-02-16

    As I said on my system I use sssd for authentication/authorization with an OpenLDAP server.
    To make the enumeration of "getent passwd" show all users you need to set "enumerate=true" in "/etc/sssd/sssd.conf". Without this setting the login to webmin with sudo users did not work (at least if the sudo group is not the primary group of the user).

    I assume many people in a larger environment use an LDAP server (OpenLDAP or ActiveDirectory) an in sssd the enumeration is false by default (which is recommended in my opinion).

    It looks like this is primary a problem of sudo and not webmin. In webmin we could think of a different method for checking if a user has sudo rights, but I have not thought about how this should be done. This method has to work on may different operating systems.

    The "bad" thing is that "sudo -l -S" works perfect on the commandline, even if the enumeration is set to false in "/etc/sssd/sssd.conf", which makes it hard to debug.

  • Jamie Cameron

    Jamie Cameron - 2016-02-16

    I suppose if there was a "sudo library" webmin could call, that would be another alternative. However, I'm not aware of any ... and even if there was, calling it from perl would require the installation of a module that would add another dependency.

  • kunzol

    kunzol - 2016-02-16

    The good thing is that I don't give up, before I solve a problem, or in other words:
    "It's never a problem, it's always a challange!"

    Getting all groups of a user can be done in several ways. The "getgrent" is one way, but it does only work, if enumeration of all groups is possible.
    The other possibility is "getgroups". This has the disadvantage, that this gives only the groups of the user of the current process. In our case the "miniserv.pl" process which has uid=0 (root).

    At the end the solution is quiet easy, because the groups are not even needed !
    I just commented out the line (and the next 2 lines) starting with "($(, $)) ..." which sets the gid (function: check_sudo_permission).
    This lets sudo run with the uid of the user and gid=0. Which is no problem, because sudo is feed with the password of the user and now checks itself for the groups of the user. This seems to be a security concept of sudo. Without gid=0 it expects that all groups of the user are already available.

    I enabled the debuglog and saw that it is really checking the sudo with password.

    I can not speak for other operating systems than debian8-amd64.

  • kunzol

    kunzol - 2016-02-16

    Next time I should stop, after I found a solution.

    Before deleting the sudo sourcecode I downloaded already, I wanted to see how they solve this group-enumeration thing. There is a glibc function "getgrouplist" and I saw that this is only used in case the "group_source" is not set to "dynamic" (see sudo.conf(5)).

    This pointed me to an even more simple solution:

    echo "Set group_source dynamic" >> /etc/sudo.conf

    Make sure that this has no other impact on the security of your system, before you configure it !!

<< < 1 2 (Page 2 of 2)

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks