All, This is a strange one. When we exec this command under puppet control:
/usr/sbin/realm permit -R AMER.COMPANY.COM [email protected] Then sssd_be core dumps (segfault). When we run that ‘realm permit’ command natively on the command line, it executes flawlessly. No core dump. Naturally, our first thought was that it’s something different in the environment. So we dumped the environment under which puppet exec resource runs. Yes, quite minimal. LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=01;36:*.au=01;36:*.flac=01;36:*.m4a=01;36:*.mid=01;36:*.midi=01;36:*.mka=01;36:*.mp3=01;36:*.mpc=01;36:*.ogg=01;36:*.ra=01;36:*.wav=01;36:*.oga=01;36:*.opus=01;36:*.spx=01;36:*.xspf=01;36: LD_LIBRARY_PATH= LANG=en_US.UTF-8 HISTCONTROL=ignoredups HOSTNAME=austgcore25.us.company.com S_COLORS=auto PWD=/root APT_LISTCHANGES_FRONTEND=none DEBIAN_FRONTEND=noninteractive APT_LISTBUGS_FRONTEND=none MAIL=/var/spool/mail/root SHELL=/bin/bash TERM=xterm SHLVL=2 MANPATH=:/opt/puppetlabs/puppet/share/man PATH=/bin:/usr/bin:/sbin:/usr/sbin HISTSIZE=1000 LESSOPEN=||/usr/bin/lesspipe.sh %s _=/bin/env But when we create a bash session with no environment, then add this puppet-supplied environment and run the above realm permit– all is still well. We can reproduce this easily in puppet. Just delete our breadcrumb file (so that puppet re-executes this ‘realm permit’ command). And execute another puppet agent run. Doing this, we obtained a core dump from sssd_be. And it points to some code in ad_id.c: [root@austgcore25 tmp]# gdb -c core-sssd_be.15405.austgcore25.us.company.com.1563210863 GNU gdb (GDB) Red Hat Enterprise Linux 8.2-5.el8 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". [New LWP 15405] Reading symbols from /usr/libexec/sssd/sssd_be...Reading symbols from /usr/lib/debug/usr/libexec/sssd/sssd_be-2.0.0-43.el8.x86_64.debug...done. done. warning: Ignoring non-absolute filename: <linux-vdso.so.1> Missing separate debuginfo for linux-vdso.so.1 Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/06/44254f9cbaa826db070a796046026adba58266 warning: .dynamic section for "/usr/lib64/libndr-nbt.so.0.0.1" is not at the expected address (wrong library or version mismatch?) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/usr/libexec/sssd/sssd_be --domain AMER.COMPANY.COM --uid 0 --gid 0 --logger=files'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f79444f53c0 in ad_get_account_domain_search (req=req@entry=0x5557b6fd45b0) at src/providers/ad/ad_id.c:1276 1276 state->filter = sdap_combine_filters(state, state->base_filter, (gdb) This is in RHEL8. What we suspect is that the shell in which puppet executes this ‘realm permit’ is not supplying something that this executable needs. If we know what it is, we can preface our puppet exec resource code snippet with the missing piece. Spike PS This ‘realm permit’ does seem to perform the correct actions eventually. It adds the expected user to the simple_allow_users line of the appropriate AD domain in /etc/sssd/sssd.conf file. But because it segfaults and then has to start up again, it takes a very long time to complete the puppet run. (There’s about 20 – 30 users + groups allowed; it has to segfault on each of them).
_______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
