Hello everyone,
I searched the list archives but could not find anything on this (nor was a web search any help at all), so I am hoping that someone here can help me figure this out.
I am going through getting started for packaging on Fedora, I have created an account at Fedora Accounts, enabled OTP, and then become stuck at the "Acquiring Kerberos Ticket" step of the Installing Packager Tools [0] instructions.
In my case, I am trying to do all of this inside of a docker container:
docker pull fedora:latest sudo docker run -t -i fedora:latest /bin/bash sudo dnf install -y fedora-packager fedora-review fkinit -u <my_fedora_accounts_username>
The only output I get is this:
Enter your password and OTP concatenated. (Ignore that the prompt is for only the token) kinit: Invalid UID in persistent keyring name while getting default ccache
There is no prompt presented.
Does this mean that it is not possible to do packaging work from inside a Docker container?
Regards,
-Roberto
[0] https://docs.fedoraproject.org/en-US/package-maintainers/Installing_Packager...
V Thu, Mar 14, 2024 at 03:02:51PM -0400, Roberto C. Sánchez napsal(a):
In my case, I am trying to do all of this inside of a docker container:
docker pull fedora:latest sudo docker run -t -i fedora:latest /bin/bash sudo dnf install -y fedora-packager fedora-review fkinit -u <my_fedora_accounts_username>
The only output I get is this:
Enter your password and OTP concatenated. (Ignore that the prompt is for only the token) kinit: Invalid UID in persistent keyring name while getting default ccache
Kerberos utils in Fedora by default store the Kerberos ticket into kernel's keyring. Kernel protects access to the keyring by matching UID of the process with the owner of the keyring. Since containers isolate a user namespace, the UID of proccesses inside the container do not match their UID from kernel's perspective. See https://blog.tomecek.net/post/kerberos-in-a-container/ for the keyctl() failure.
Many people "solve" it by reconfiguring the Kerberos utils to save the tickets into a file instead into a kernel memmory. E.g. with setting KRB5CCNAME environement variable to "FILE:..." value. (This is the case of the linked blog.) Or with commenting out default_ccache_name option in the in-container /etc/krb5.conf configuration file.
Another option is disabling the user naspace isolation of the container.
What the correct, in the sense of using kernel keyring, solution is I have no idea.
-- Petr
Hi Petr,
On Fri, Mar 15, 2024 at 09:07:55AM +0100, Petr Pisar wrote:
V Thu, Mar 14, 2024 at 03:02:51PM -0400, Roberto C. Sánchez napsal(a):
In my case, I am trying to do all of this inside of a docker container:
docker pull fedora:latest sudo docker run -t -i fedora:latest /bin/bash sudo dnf install -y fedora-packager fedora-review fkinit -u <my_fedora_accounts_username>
The only output I get is this:
Enter your password and OTP concatenated. (Ignore that the prompt is for only the token) kinit: Invalid UID in persistent keyring name while getting default ccache
Kerberos utils in Fedora by default store the Kerberos ticket into kernel's keyring. Kernel protects access to the keyring by matching UID of the process with the owner of the keyring. Since containers isolate a user namespace, the UID of proccesses inside the container do not match their UID from kernel's perspective. See https://blog.tomecek.net/post/kerberos-in-a-container/ for the keyctl() failure.
OK. That is very helpful. The last time I had to deal with any sort of Kerberos environment containers were not yet a thing.
That article is rather interesting and informative.
Many people "solve" it by reconfiguring the Kerberos utils to save the tickets into a file instead into a kernel memmory. E.g. with setting KRB5CCNAME environement variable to "FILE:..." value. (This is the case of the linked blog.) Or with commenting out default_ccache_name option in the in-container /etc/krb5.conf configuration file.
OK. Either of these seem like viable solutions in my case. I'll give the article another read-through and then implement its suggestion, or the other if it seems that will make for a smoother workflow.
Another option is disabling the user naspace isolation of the container.
I suppose that would also accomplish a number of other things too :-)
What the correct, in the sense of using kernel keyring, solution is I have no idea.
Given that in my case the sole purpose is to do some packaging work, I think either of KRB5CCNAME or changing /etc/krb5.conf are "correct".
Thanks very much for the assitance and the pointer to the blog article.
Regards,
-Roberto
packaging@lists.fedoraproject.org
-
Petr Pisar -
Roberto C. Sánchez