> generated a Kerberos TGT This is my main suspect. If you are generating it manually, it will not be in desktop's environment.
So please try to get authenticated by the server by using [email protected] in the log-in screen (GDM). If it also fails, please share the output of snap run --shell firefox -c 'env|grep KRB' And thank you for your willingness to give this a go. -- 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: [SRU] kerberos GSSAPI no longer works after deb->snap transition Status in Mozilla Firefox: New Status in snapd: Fix Released Status in chromium-browser package in Ubuntu: Fix Released Status in firefox package in Ubuntu: In Progress Status in snapd package in Ubuntu: Fix Released Status in snapd source package in Jammy: New Status in snapd source package in Noble: New Status in snapd source package in Plucky: New Status in snapd source package in Questing: Fix Released Bug description: [SRU] 2.71: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/2118396 [ Impact ] Programs that use Kerberos do not have access to Kerberos' tickets (by default, /tmp/krb5cc*) if snapped, resulting in denied access to documents that the user would otherwise be able to access if the program weren't snapped. [ Test Plan ] Requires a server that uses Kerberos authentication and a Ubuntu client, that for the following tests is presumed to have logged into the server's realm. 1. Reproduce on snapd deb < 2.71 Install the Firefox snap. Expect: - websites that used to work with SPNEGO/GSSAPI/kerberos do not work (access denied). - 'snap connect firefox:kerberos-tickets' fails because Snapd < 2.71 does not yet have the corresponding slot. 2. Prove fix on snapd 2.71 First connect the new plug: snap connect firefox:kerberos-tickets Then access a document from said server, it should work. [ Regression potential ] Unauthorized snaps (i.e., without kerberos-tickets connection) have access to the tickets. Snaps fail to launch due to some bug in the implementation logic merged in https://github.com/canonical/snapd/pull/15519. ---original--- 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 : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
