Bug 1630187

Summary:	[RFE] adcli join should preserve SPN added by adcli preset-computer
Product:	Red Hat Enterprise Linux 7	Reporter:	Petr Čech <pcech>
Component:	adcli	Assignee:	Sumit Bose <sbose>
Status:	CLOSED ERRATA	QA Contact:	ipa-qe <ipa-qe>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.6	CC:	dpal, lslebodn, pcech, sgoveas
Target Milestone:	rc	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	adcli-0.8.1-9.el7	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-08-06 13:11:03 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 Petr Čech 2018-09-18 07:29:55 UTC

Description of problem:


Version-Release number of selected component (if applicable):
adcli-0.8.1-6.el7


How reproducible:
Firstly, preset computer with option --service-name, then do adcli join.

Steps to Reproduce:
1. adcli preset-computer --service-name abc
2. adcli join
3. check, if spn abc is still present

Actual results:
adcli join rewrite all preset SPNs

Expected results:
adcli join preserve preset SPNs

Additional info:
There is a workaround:
1. adcli preset-computer --service-name abc
2. adcli join --service-name abc

Comment 4 Sumit Bose 2019-03-22 11:01:06 UTC

Upstream commits:
 - https://gitlab.freedesktop.org/realmd/adcli/commit/3a84c2469c31967bc22c0490456f07723ef5fc86
 - https://gitlab.freedesktop.org/realmd/adcli/commit/e1b45e66bc185f5db4c252e1f3fb1b4400b4538e
 - https://gitlab.freedesktop.org/realmd/adcli/commit/10a4dbb5978b6f05cf75f820d97da908e735ace8
 - https://gitlab.freedesktop.org/realmd/adcli/commit/972f1a2f35829ed89f5353bd204683aa9ad6a2d2

Comment 6 Sumit Bose 2019-04-15 08:38:37 UTC

*** Bug 1693092 has been marked as a duplicate of this bug. ***

Comment 7 Sumit Bose 2019-04-15 16:28:29 UTC

(In reply to Sumit Bose from comment #4)
> Upstream commits:
>  - https://gitlab.freedesktop.org/realmd/adcli/commit/3a84c2469c31967bc22c0490456f07723ef5fc86
>  - https://gitlab.freedesktop.org/realmd/adcli/commit/e1b45e66bc185f5db4c252e1f3fb1b4400b4538e
>  - https://gitlab.freedesktop.org/realmd/adcli/commit/10a4dbb5978b6f05cf75f820d97da908e735ace8
>  - https://gitlab.freedesktop.org/realmd/adcli/commit/972f1a2f35829ed89f5353bd204683aa9ad6a2d2

Additionally

 - https://gitlab.freedesktop.org/realmd/adcli/commit/a64cce9830c2e9c26e120f671b247ee71b45c888

is needed.

Comment 8 Lukas Slebodnik 2019-04-15 20:06:26 UTC

(In reply to Sumit Bose from comment #7)
> Additionally
> 
>  -
> https://gitlab.freedesktop.org/realmd/adcli/commit/
> a64cce9830c2e9c26e120f671b247ee71b45c888
> 
> is needed.

Return value of strdup is check on many places in  library/adenroll.c
e.g. https://gitlab.freedesktop.org/realmd/adcli/blob/master/library/adenroll.c#L1554

Is there any reason why it was not checked in commit a64cce9830c2e9c ?

Comment 9 Sumit Bose 2019-04-16 07:54:13 UTC

Hi Lukas,

thank you for the comment. _adcli_strv_add_unique() call _adcli_strv_add() which does the NULL check and returns the unmodified list in this case. Using strdup() in the argument list of _adcli_strv_add() is a typical pattern in the current adcli code and so I used it here as well.

I think the question is if the NULL should be treated as an error or if it should be ignored and processing should continue. You know that in SSSD I typically tend to error out as soon as possible but I think adcli has a different philosophy here. Given that I might not always pick the right choice and while looking at your example I wonder if it might be more consistent to ignore the NULL in load_keytab_entry() for the service principals as well?

Btw, are you interested in doing code reviews for adcli and/or realmd? If yes, please let me know on which terms.

bye,
Sumit

Comment 13 errata-xmlrpc 2019-08-06 13:11:03 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2019:2256