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