issue with sudo_ldap

Dagobert Michelsen dam at opencsw.org
Mon Nov 7 13:09:34 CET 2016


Hi Stefan,

Am 07.11.2016 um 11:52 schrieb Stefan Maass <stefan.maass at syniverse.com>:
> 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 at 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 at 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 at 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 at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opencsw.org/pipermail/users/attachments/20161107/3a34280a/attachment.asc>


More information about the users mailing list