The following case has been opened with RHEL support on this. It was
opened this morning:
(SEV 4) Case #02427449 ('realm permit group@DOMAIN' causing background
process sssd_be to segfault.)
Spike
On Mon, Jul 15, 2019 at 4:01 PM Jakub Hrozek <[email protected]> wrote:
> On Mon, Jul 15, 2019 at 12:50:03PM -0500, Spike White wrote:
> > 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).
>
> Anytime sssd_be segfaults, it is a bug. Could you file a bug or a
> support case (since you mentioned RHEL). In case you file a support
> case, feel free to send me the number so we can follow up.
>
> It would be nice to attach the core and logs etc to the case or the bug,
> because our tests make use of realm permit and we have not hit the bug
> so far.
>
> >
> > 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]
> _______________________________________________
> 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]
>
_______________________________________________
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]
