koji

#3680 [1.31.1] possible securiry problem when having multiple principal's
Closed: Fixed by tkopecek. Opened by frank-mdc.

Closed: Fixed
Reopen Issue

I have found out that the parameter "--principal=" does not work as expected.
Environment:
- the local user will have to TGT's one for foo@REALM and one for foo-adm@REALM
- in the user database for koji both users will have admin rights.
When calling:
koji --principal=foo-adm@REALM revoke-permission admin 'foo'
user foo will normally lose it admins rights.
koji --principal=foo-adm@REALM list-permissions --user 'foo'
Permission name

So it will looks correct. In the sql database all will be correct ( I have verified it).
Now it will becomes very interesting:
koji --principal=foo@REALM list-permissions --mine
Permission name

admin

The reason for it will be, that foo-adm@REAM will be used instant of foo@REALM for login.
This can I see on the apache logs of the hub system.
Also the debug mode will shown it:
KRB5_TRACE=/dev/stdout koji -d --principal= foo@REALM list-permissions --mine
2023-02-10 08:34:59,829 [DEBUG] koji: Opening new requests session
2023-02-10 08:34:59,830 [DEBUG] koji: Opening new requests session
[747491] 1676014499.866392: ccselect module realm chose cache KCM:1000:26473 with client principal foo-adm@REAM for server principal HTTP/server@REALM
[747491] 1676014499.866393: Getting credentials foo-adm@REAM -> HTTP/server@ using ccache KCM:1000:26473
[747491] 1676014499.866394: Retrieving foo-adm@REAM -> krb5_ccache_conf_data/start_realm@X-CACHECONF: from KCM:1000:26473 with result: -1765328243/Matching credential not found
[747491] 1676014499.866395: Retrieving foo-adm@REAM -> HTTP/server@ from KCM:1000:26473 with result: 0/Success
[747491] 1676014499.866397: Creating authenticator for foo-adm@REAM -> HTTP/server@, seqnum 155179470, subkey aes256-cts/8533, session key aes256-cts/F81D
successfully connected to hub
Permission name

admin

Hmm, it is more about documentation. --principal makes sense only for keytab authentication. For kinit it doesn't make much sense and it is ignored. Would be help string update reasonable?

Metadata Update from @tkopecek:
- Custom field Size adjusted to None

I think so. The text can be:
"specify a Kerberos principal to use from the keytab file (--keytab)"
And the same for the user option, because it will sound so as can you specify the user name.
But it sounds like when using kerberos with more then one TGT, koji will use the TGT which was created at last.

I think I found the real problematic code.
You can easy set up the second principal when call:
gssapi.Credentials(name=gssapi.Name(PRINCIPAL, gssapi.NameType.user) ,usage='initiate')
instant of:
gssapi.Credentials(usage='initiate')
So, PRINCIPAL must only be filled with the value of the setting of "--principal"
But i have no knowledge where it is done in the koji code.
Here my sample test code:

print(gssapi.Credentials(usage='initiate').name)
print(gssapi.Credentials(name=gssapi.Name("foo-adm@REALM", gssapi.NameType.user) ,usage='initiate').name)
print(gssapi.Credentials(name=gssapi.Name("invalid@REALM", gssapi.NameType.user) ,usage='initiate').name)

This will output:
foo
foo-adm
Traceback (most recent call last) .. because the last is an invalid TGT.
Edited by frank-mdc

"user" is used for user/password auth. In case that "user" is present, this type of auth will be enforced. Otherwise it is not used for anything.
principal is not set without keytab at all. It is all in these few lines: https://pagure.io/koji/blob/master/f/cli/koji_cli/lib.py#_747

This can then very simple be fixed.
I will try it out on my system and when it will works, I will create an PR.

Done: https://pagure.io/koji/pull-request/3683

Metadata Update from @tkopecek:
- Issue set to the milestone: 1.33
  • PR #3686
Edited by tkopecek

Metadata Update from @tkopecek:
- Issue tagged with: testing-ready

Metadata Update from @mfilip:
- Issue tagged with: testing-done

Commit b715e530 fixes this issue

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/koji/koji/issues/3680

Please continue any further discussion there.
Metadata
None

testing-done testing-ready

None
None
Low
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.