Hi Dagobert, Thanks for your reply!
I had seen the entry in the change log that you have mentioned below and I have tried using the -g switch as well, but it did not change anything. It just added one line into the output of the debug log other than that it does nothing and I am still not allowed to sudo as I was in the former sudo version. Nov 7 13:37:36 sudo[158099] will restore signal 13 on exec Nov 7 13:37:36 sudo[158099] settings: runas_group=global_sysadmin Nov 7 13:37:36 sudo[158099] settings: progname=sudo Nov 7 13:37:36 sudo[158099] settings: network_addrs=10.161.120.147/255.255.254.0 10.161.146.18/255.255.255.0 10.161.146.26/255.255.255.0 Nov 7 13:37:36 sudo[158099] settings: plugin_dir=/opt/csw/libexec/sudo/ Nov 7 13:37:36 sudo[158099] policy plugin returns 0 It looks like it does not find the policy in LDAP that matches the right to switch user. The other changes that have been done in regards of LDAP don't say much to me for now so I am not sure if they could be responsible for what I am facing. Regards, Stefan -----Ursprüngliche Nachricht----- Von: Dagobert Michelsen [mailto:[email protected]] Gesendet: Montag, 7. November 2016 13:10 An: Stefan Maass <[email protected]> Cc: [email protected] Betreff: Re: issue with sudo_ldap Hi Stefan, Am 07.11.2016 um 11:52 schrieb Stefan Maass <[email protected]>: > It looks like we ran into a new issue and I hope you are the right person to > contact. At least I can see that the package (I think) is involved has been > packaged by you. > > I have recently done an upgrade of a few packages including sudo and > sudo_ldap on a few nodes. The former versions were as follows: > > CSWsudo à VERSION: 1.8.16,REV=2016.03.18 > CSWsudo-ldap à VERSION: 1.8.16,REV=2016.03.18 > > The new versions are: > > CSWsudo à VERSION: 1.8.18,REV=2016.09.21 > CSWsudo-ldap à VERSION: 1.8.18,REV=2016.09.21 > > Interestingly on the servers with the older version and also on the servers > with the newer version the command /opt/csw/bin/pkgutil --version > CSWsudo-ldap shows 2.6.7. So it looks like it is in fact the same package. pkgutil —version shows the version of pkgutil. Try > dam@unstable10s [unstable10s]:/home/dam > pkgutil -c sudo sudo_ldap > You're not root and didn't set -W, using home dir. > => Fetching new catalog and descriptions > (file:///export/mirror/opencsw-official/unstable/sparc/5.10) if available ... > ==> 3948 packages loaded from > /home/dam/.pkgutil/catalog._export_mirror_opencsw-official_unstable_sparc_5.10 > package installed catalog > CSWsudo 1.8.18p1,REV=2016.10.28 SAME > The issue that we have is that since I have upgraded the sudo packages LDAP > users are not able anymore to use sudo as it seems that the information from > the LDAP server is not received. > > This example output is from a server where sudo works: > > pts/23|root@fr4u-gen-chs-app001:/root# sudo su - g701806 > sudo: start_tls specified but LDAP libs do not support ldap_start_tls_s() or > ldap_start_tls_s_np() > Oracle Corporation SunOS 5.10 Generic Patch January 2005 > LOGIN NAME: g701806 > ORACLE DATABASE: chdev > Clearing House profile executed. > development environment for server fr4u-gen-chs-app001 set! > fr4u-gen-chs-app001:DEVELOP\&chdev\&/ldap/home/g701806: sudo su - > sudo: start_tls specified but LDAP libs do not support ldap_start_tls_s() or > ldap_start_tls_s_np() > Oracle Corporation SunOS 5.10 Generic Patch January 2005 > pts/23|root@fr4u-gen-chs-app001:/root# ^D > fr4u-gen-chs-app001:DEVELOP\&chdev\&/ldap/home/g701806: sudo -l > sudo: start_tls specified but LDAP libs do not support > ldap_start_tls_s() or ldap_start_tls_s_np() Matching Defaults entries for > g701806 on fr4u-gen-chs-app001: > loglinelen=0, logfile=/var/adm/sudolog, ignore_dot, !mail_no_user, > log_host, logfile=/var/log/sudolog, !syslog, > timestamp_timeout=10, !authenticate > > User g701806 may run the following commands on fr4u-gen-chs-app001: > (root) ALL > > This example output is from a server where sudo does not work: > > pts/5|root@fr4u-gen-chs-app002:/var/log# sudo su - g701806 > sudo: start_tls specified but LDAP libs do not support ldap_start_tls_s() or > ldap_start_tls_s_np() > Oracle Corporation SunOS 5.10 Generic Patch January 2005 > LOGIN NAME: g701806 > ORACLE DATABASE: chdev > Clearing House profile executed. > development environment for server fr4u-gen-chs-app002 set! > fr4u-gen-chs-app002:DEVELOP\&chdev\&/ldap/home/g701806: sudo su - > sudo: start_tls specified but LDAP libs do not support > ldap_start_tls_s() or ldap_start_tls_s_np() > g701806 is not allowed to run sudo on fr4u-gen-chs-app002. This incident > will be reported. > fr4u-gen-chs-app002:DEVELOP\&chdev\&/ldap/home/g701806: sudo -l > sudo: start_tls specified but LDAP libs do not support > ldap_start_tls_s() or ldap_start_tls_s_np() Sorry, user g701806 may not run > sudo on fr4u-gen-chs-app002. > > I am not sure if this output helps, but I have added a line to sudo.conf to > debug sudo. So here is what appears in the sudo_debug log when I execute the > command “sudo su –“ on the server where sudo works: > > Nov 7 11:13:42 sudo[535884] settings: progname=sudo Nov 7 11:13:42 > sudo[535884] settings: network_addrs=10.161.120.146/255.255.254.0 > 10.161.146.17/255.255.255.0 10.161.146.25/255.255.255.0 Nov 7 > 11:13:42 sudo[535884] settings: plugin_dir=/opt/csw/libexec/sudo/ Nov > 7 11:13:43 sudo[535884] policy plugin returns 1 Nov 7 11:13:43 > sudo[535884] settings: progname=sudo Nov 7 11:13:43 sudo[535884] > settings: network_addrs=10.161.120.146/255.255.254.0 > 10.161.146.17/255.255.255.0 10.161.146.25/255.255.255.0 Nov 7 11:13:43 > sudo[535884] settings: plugin_dir=/opt/csw/libexec/sudo/ Nov 7 11:13:43 > sudo[535884] command info from plugin: > Nov 7 11:13:43 sudo[535884] 0: command=/usr/bin/su > Nov 7 11:13:43 sudo[535884] 1: runas_uid=0 > Nov 7 11:13:43 sudo[535884] 2: runas_gid=0 > Nov 7 11:13:43 sudo[535884] 3: runas_groups=0,1,2,3,4,5,6,7,8,9,12 > Nov 7 11:13:43 sudo[535884] 4: closefrom=3 > Nov 7 11:13:43 sudo[535884] 5: set_utmp=true > Nov 7 11:13:43 sudo[535884] 6: umask=022 > Nov 7 11:13:43 sudo[535884] executed /usr/bin/su, pid 535901 Nov 7 > 11:13:43 sudo[535884] sudo_ev_add_v1: adding event 44628 to base 4b4d0 > Nov 7 11:13:43 sudo[535884] sudo_ev_add_v1: adding event 44668 to > base 4b4d0 Nov 7 11:13:43 sudo[535884] signal pipe fd 7 Nov 7 > 11:13:43 sudo[535884] backchannel fd 9 Nov 7 11:13:43 sudo[535901] > exec /usr/bin/su [su -] Nov 7 11:13:43 sudo[535884] > sudo_ev_scan_impl: 1 fds ready Nov 7 11:13:43 sudo[535884] failed to > read child status: EOF Nov 7 11:13:43 sudo[535884] sudo_ev_del_v1: > removing event 44668 from base 4b4d0 > > And here is the output from the server where sudo does not work: > > Nov 7 11:12:02 sudo[152587] will restore signal 13 on exec Nov 7 > 11:12:02 sudo[152587] settings: progname=sudo Nov 7 11:12:02 > sudo[152587] settings: network_addrs=10.161.120.147/255.255.254.0 > 10.161.146.18/255.255.255.0 10.161.146.26/255.255.255.0 Nov 7 > 11:12:02 sudo[152587] settings: plugin_dir=/opt/csw/libexec/sudo/ Nov > 7 11:12:02 sudo[152587] policy plugin returns 0 Maybe a look in the Changelog helps: https://www.sudo.ws/changes.html * plugins/sudoers/ldap.c, plugins/sudoers/sssd.c: Fix matching when no sudoRunAsUser is present in a sudoRole. If only a sudoRunAsGroup is present, match on the invoking user if the -g option was specified and the group matched. If no sudoRunAsGroup is present and the -g option was specified, allow it if it matches the passwd gid of the runas user. This matches the behavior of the sudoers backend. [e1a52c34da5e] There are also a few other changes, I suggest you take a look and make sure you didn’t hit one of these before digging in further. You may also wanto to cc: sudo-users@: https://www.sudo.ws/mailman/listinfo/sudo-users Best regards — Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896
