The same rule works as expected if defined in the local sudoers file. I think the problem is that secure_path in "Options" from IPA isn't taken into account.
As described, if I add the path to the one i local sudoers the sudo command from IPA works. ----- On Feb 15, 2017, at 2:38 PM, Jakub Hrozek [email protected] wrote: > On Wed, Feb 15, 2017 at 11:04:47AM +0100, Troels Hansen wrote: >> Hi there >> >> We have a strange problem....... >> >> We're trying to override options in sudo rules from IPA, in this case >> secure_path: >> >> sudo -ll reports: >> >> RunAsUsers: root >> Options: requiretty, lecture=always, timestamp_timeout=0, !authenticate, >> secure_path=/bin:/usr/bin:/usr/local/bin >> Commands: >> stopinst >> /usr/local/bin/stopinst >> /usr/local/bin/startinst >> /bin/mount /rman >> /usr/bin/su - root >> >> /usr/local/bin is also in my local path: >> >> $ echo $PATH >> /usr/local/bin:/usr/bin:/usr/local/sbin.......... >> >> For easyness, stopinst is currently quite simple: >> >> $ cat /usr/local/bin/stopinst >> #!/bin/bash >> echo stopinst >> echo "Path: $PATH" >> >> I can execute the script a normal user, using full path or just the command: >> $ stopinst >> stopinst >> Path: >> /usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/net.dr.dk/drextrha/.local/bin:/home/net.dr.dk/drextrha/bin >> >> However, trying to execute the script using sudo fails: >> $ sudo stopinst >> [sudo] password for drextrha: >> sudo: stopinst: command not found >> >> Unless using full path: >> $ sudo /usr/local/bin/stopinst >> stopinst >> Path: /bin:/usr/bin:/usr/local/bin >> >> Secure path in sudoers is: >> # grep secure_path /etc/sudoers >> Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin >> >> If I change the secure_path in local sudoers to include /usr/local/bin: >> # grep secure_path /etc/sudoers >> Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin >> >> I can execute the command using sudo: >> >> $ sudo stopinst >> stopinst >> Path: /bin:/usr/bin:/usr/local/bin >> >> Soooo...... something gets overwritten somewhere that shouldn't??? > > We shouldn't rewrite anything on the SSSD side. In general, when it > comes to delivering SUDO rules, SSSD should more or less just act as a > proxy. > > Did you try to define a similar rule locally in /etc/sudoers to see if > the same issue happens with a local rule? That should at least confirm > or deny that the issue might be in SSSD. > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project -- Med venlig hilsen Troels Hansen Systemkonsulent Casalogic A/S T (+45) 70 20 10 63 M (+45) 22 43 71 57 Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
