Bug 2133818

Summary:	rpcclient 4.17.0 unable to resolve server hostname
Product:	[Fedora] Fedora	Reporter:	Florence Blanc-Renaud <frenaud>
Component:	samba	Assignee:	Andreas Schneider <asn>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	37	CC:	abokovoy, aboscatt, anoopcs, asn, gdeschner, iboukris, jarrpa, jstephen, lmohanty, madam, pfilipen, sbose, ssorce
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	samba-4.17.1-1.fc38 samba-4.17.1-1.fc37	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-10-19 15:41:28 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Florence Blanc-Renaud 2022-10-11 13:54:46 UTC

Description of problem:

With rpcclient 4.17.0, the following command exits on error
$ rpcclient --use-kerberos=desired root-dc.ad.test -c 'deletetrustdom testrelm.test'
Cannot connect to server.  Error was NT_STATUS_NOT_FOUND

Version-Release number of selected component (if applicable):
4.17.0 on fedora 37

How reproducible:
Always

Steps to Reproduce:
1. install ipa server with
$ ipa-server-install --domain testrelm.test --realm TESTRELM.TEST --setup-dns --no-dnssec-validation --auto-forwarders -a Secret123 -p Secret123 -U
$ echo Secret123 | kinit admin
$ ipa-adtrust-install --add-sids -a Secret123 --enable-compat -U
$ ipa dnsforwardzone-add ad.test --forward-policy=only --forwarder=<IP address of root-dc.ad.test>

2. configure dns forwarder on AD side
dnscmd 127.0.0.1 /ZoneAdd testrelm.test /Forwarder <IP address of IPA server>

3. Establish external trust
$ ipa trust-add --type ad ad.test --range-type ipa-ad-trust --external=True --admin Administrator --passw
ord

4. try to remove the trust from AD side:
$ kinit Administrator
$ rpcclient --use-kerberos=desired root-dc.ad.test -c 'deletetrustdom testrelm.test'

Actual results:
The rpcclient command fails

Expected results:
The command should work

Additional info:
When the command is run in debug mode, we see the following output:
$ rpcclient --debuglevel 10 --debug-stdout --use-kerberos=desired root-dc.ad.test -c 'deletetrustdom testrelm.test'
[...]
internal_resolve_name: looking up ���y�U#20 (sitename (null))
convert_string_talloc_handle: Conversion error: Incomplete multibyte sequence
resolve_lmhosts: Attempting lmhosts lookup for name ���y�U<0x20>
getlmhostsent: lmhost entry: 127.0.0.1 localhost 
resolve_wins: WINS server resolution selected and no WINS servers listed.
resolve_hosts: Attempting host lookup for name ���y�U<0x20>
resolve_hosts: getaddrinfo failed for name ���y�U [Name or service not known]
name_resolve_bcast: Attempting broadcast lookup for name ���y�U<0x20>
convert_string_talloc_handle: Conversion error: Incomplete multibyte sequence
convert_string_handle: Conversion error: Incomplete multibyte sequence
tstream_unix_connect failed: No such file or directory
nmbd not around
Cannot connect to server.  Error was NT_STATUS_NOT_FOUND
msg_dgm_ref_destructor: refs=(nil)
$

It looks like the hostname is garbled.
I don't know if this applies to rpcclient code but popt 1.19 fixed a memory leak and programs using popt may be broken if they were calling popFreeContext() and accessing the options after this call (see for instance https://bugzilla.redhat.com/show_bug.cgi?id=2100287)

The issue with rpcclient was seen on freeipa nightly tests, and reported at https://pagure.io/freeipa/issue/9239

Comment 1 Guenther Deschner 2022-10-11 15:40:30 UTC

Can you try if instead of running

rpcclient --use-kerberos=desired root-dc.ad.test -c 'deletetrustdom testrelm.test'

give the hostname as part of a dcerpc binding string like:

rpcclient --use-kerberos=desired ncacn_np:root-dc.ad.test -c 'deletetrustdom testrelm.test'

makes a difference?

Comment 2 Florence Blanc-Renaud 2022-10-12 10:48:02 UTC

The result is the same. I really suspect that the issue is related to popt 1.19 because rpcclient is calling poptFreeContext and later on refers to values obtained with popt but that have been freed. Easy to see with a debugger, printing server before/after the call to poptFreeContext (https://github.com/samba-team/samba/blob/master/source3/rpcclient/rpcclient.c#L1249) produces different results. Before the free, the value is ok, but after the free it's completely random:

(gdb) print(server)
$1 = 0x5555556e0fa0 "ncacn_np:root-dc.ad.test"
(gdb) n
1249		poptFreeContext(pc);
(gdb) n
1250		samba_cmdline_burn(argc, argv);
(gdb) print(server)
$2 = 0x5555556e0fa0 "\340\304;"

Comment 3 Andreas Schneider 2022-10-18 12:17:44 UTC

This already has been addressed upstream: https://bugzilla.samba.org/show_bug.cgi?id=15205

We will get Samba 4.17.1 next week which will fix it.

Comment 4 Fedora Update System 2022-10-19 15:37:25 UTC

FEDORA-2022-314a73e994 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2022-314a73e994

Comment 5 Fedora Update System 2022-10-19 15:41:28 UTC

FEDORA-2022-314a73e994 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 6 Fedora Update System 2022-10-19 20:19:41 UTC

FEDORA-2022-1b0ba70aca has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-1b0ba70aca

Comment 7 Fedora Update System 2022-10-21 14:40:55 UTC

FEDORA-2022-1b0ba70aca has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-1b0ba70aca`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-1b0ba70aca

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 8 Fedora Update System 2022-10-24 17:50:53 UTC

FEDORA-2022-1b0ba70aca has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.