> What exactly "not work" means here, i.e., what exactly did you do? In
your last comment you set default_ccache_name to a different directory
than what I tried in my test case. Did you reboot after the change, did
you verify the tickets were created in the new location, or were they
still in the old place?
I edited the Kerberos configuration file (under '/etc/krb5.conf.d',
which is included by 'includedir /etc/krb5.conf.d/' in '/etc/krb5.conf')
to contain the line 'default_ccache_name = FILE:/home/wtcline/krb5cc'
under the '[libdefaults]' section. I then ran 'kinit' in order to get a
new TGT:
wtcline@wtcline-desk13:~$ klist
Ticket cache: FILE:/home/wtcline/krb5cc
Default principal: wtcl...@redacted.com
Valid starting Expires Service principal
04/02/2025 09:59:12 04/02/2025 19:59:12 krbtgt/redacted....@redacted.com
renew until 04/03/2025 09:59:05
Then I opened up Firefox and navigated to an internal site which
requires Kerberos and got an HTTP 401 error.
I also tried 'FILE:/run/user/%{euid}/krb5cc' but have the same issue.
> That is a reasonable expectation, but in snaps /tmp just cannot work
since every snap has a private tmp. Yes, we do not want to pollute
people's home directory and that's not what we're going for as per my
last comment. It's just the easy way for testing.
There's no way to punch a hole for a specific file path? That's too
bad.
> This might also apply to other Kerberos libraries besides MIT Kerberos
and SSSD (if there are any, I don't know).
There's potentially 'winbind', but we're not using it on Ubuntu.
> The kerberos is one, but the other one is the issue of snap packages
not using the system certificate store, preventing secure use of
organizational CAs.
I wonder if that is part of what's going on here. For the Firefox Snap
we use the policy 'SecurityDevices' in order to point Firefox to
'/usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so' which causes the
Firefox Snap to use the organizational CAs included in the system trust
store. Based on old code comments, this didn't appear to work in 20.04
(probably), but it does work in 22.04 and 24.04.
I'm not sure how the 'SecurityDevices' policy interacts with Kerberos.
I'd guess that the Firefox Snap and Kerberos libraries are separate in
this regard. Especially given that 'SecurityDevices' pointing to
p11-kit is working in 24.04 while Kerberos is not (at least for our set-
up).
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1849346
Title:
[snap] kerberos GSSAPI no longer works after deb->snap transition
Status in Mozilla Firefox:
New
Status in snapd:
New
Status in chromium-browser package in Ubuntu:
In Progress
Status in firefox package in Ubuntu:
In Progress
Bug description:
Workaround
----------
Add
default_ccache_name = FILE:/run/user/%{euid}/krb5cc
to the [libdefaults] section of /etc/krb5.conf so that the Kerberos
credentials are stored in a file path a snapped application can read.
Acknowledgement: For many that can't work for {different reasons}, as
stated in multiple comments below. Nonetheless it is worth a mention.
Original report
---------------
I configure AuthServerWhitelist as documented:
https://www.chromium.org/developers/design-documents/http-
authentication
and can see my whitelisted domains in chrome://policy/
but websites that used to work with SPNEGO/GSSAPI/kerberos no longer
work. I'm guessing the snap needs some sort of permission to use the
kerberos ticket cache (or the plumbing to do so doesn't exist...).
I can confirm that Chrome has the desired behavior.
To manage notifications about this bug go to:
https://bugs.launchpad.net/firefox/+bug/1849346/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
