> The configuration files appear to be readable in the sandbox, but I'm
not seeing the ticket available there even after running 'kinit' outside
of the sandbox and then 'snap connect firefox:kerberos-tickets'.
That is expected because Snapd relies on KRB5CCNAME to expose the ticket
to a place from which the snap can read the ticket.
What you could try is to manually run
KRB5CCNAME=FILE:/tmp/krb5cc_{ETC} firefox
where /tmp/krb5cc_{ETC} is the ticket's path as you see outside the
sandbox.
> These systems aren't domain-joined, so a ticket is not created by
logging in, which I think is what you're expecting to happen. I can't
login with my external e-mail, just as a local user.
Indeed, I was expecting that workflow. I did not know that one logs in
as a normal user. But after a Kinit, your KRB5CCNAME is set-up in the
environment, correct? Then try to launch Firefox from that terminal
where you did Kinit.
> Does the 'firefox:kerberos-tickets' plug allow access to tickets in
'/tmp'?
Not really, because /tmp is private to every snap so the host's /tmp is
entirely invisible inside the snap sandbox.
> Either way, I think the issue establishing HTTPS connection must first
be solved before I can really test Kerberos with this Snap. Is there
some prerequisite reading I should go through before trying to test the
Firefox snap package?
Not really; Also I am certainly missing bits of knowledge to grasp what
is going on in your case. It must be the interaction with certificates
but my test case doesn't include that. I'll keep looking and will ask
around but feel free to share documents that might help me understand
the issue further, if you have any.
> And thank you for working on a fix!
My pleasure!
--
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
