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
signature.asc
Description: Message signed with OpenPGP using GPGMail
