> 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.
The trust issue appears to have been a result of the following policy:
"SecurityDevices": {
"p11-kit-trust.so for corporate certificate chain":
"/usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so"
}
The issue does appear to persist across restarts of Firefox even after
removing the policy (though I'd need to reconfirm this), though removing
'~/snap/firefox/common/.mozilla/' appears to fix this (and wipes the
browser configuration, so careful). This appears to be a regression,
but it is unrelated to this issue.
Unfortunately, the above mechanism was how I was configuring trust for
our internal root CAs, so I needed a workaround. The workaround was to
copy each certificate manually into the the following directory:
'~/snap/firefox/common/.mozilla/certificates/' and then create a Firefox
policy telling Mozilla to trust each of these Root CAs:
"Certificates": {
"Install": [
"/home/wtcline/snap/firefox/common/.mozilla/certificates/CorporateCA1.crt",
"/home/wtcline/snap/firefox/common/.mozilla/certificates/CorporateCA2.crt",
"/home/wtcline/snap/firefox/common/.mozilla/certificates/CorporateCA3.crt",
]
}
> 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.
Nope. My understanding is that most programs will prioritize
'KRB5CCNAME' if and only if it's set, otherwise they will use the value
specified in the 'krb5.conf' or 'krb5.cond.d/*' file(s) (presumably
parsed by a library that said program links with).
> 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.
I've not had any luck getting that environment variable passed to
Firefox... I think? I say "I think" because no matter what happens I've
yet to see the environment variable listed in Firefox's 'about:support'
page.
I first tried what appeared to be the proper way, but got an error:
wtcline@wtcline-desk20:~$ sudo snap set firefox
env.KRB5CCNAME="FILE:/tmp/krb5cc_1000"
error: cannot perform the following tasks:
- Run configure hook of "firefox" snap (invalid option name:
"KRB5CCNAME")
Yet if I set 'KRB5CCNAME=/tmp/krb5cc_1000' in '/etc/environment' and
reboot then I can get output like the following:
wtcline@wtcline-desk20:~$ snap run --shell firefox -c 'env|grep KRB'
2025/09/03 17:44:39.874455 cmd_run.go:1408: WARNING: will not expose
Kerberos tickets' path: Unsupported KRB5CCNAME: /tmp/krb5cc_1000
update.go:85: cannot change mount namespace according to change mount
(/var/lib/snapd/hostfs/usr/local/share/doc /usr/local/share/doc none bind,ro 0
0): cannot write to "/var/lib/snapd/hostfs/usr/local/share/doc" because it
would affect the host in "/var/lib/snapd"
update.go:85: cannot change mount namespace according to change mount
(/var/lib/snapd/hostfs/usr/share/gimp/2.0/help /usr/share/gimp/2.0/help none
bind,ro 0 0): cannot write to "/var/lib/snapd/hostfs/usr/share/gimp/2.0/help"
because it would affect the host in "/var/lib/snapd"
update.go:85: cannot change mount namespace according to change mount
(/var/lib/snapd/hostfs/usr/share/gtk-doc /usr/share/gtk-doc none bind,ro 0 0):
cannot write to "/var/lib/snapd/hostfs/usr/share/gtk-doc" because it would
affect the host in "/var/lib/snapd"
update.go:85: cannot change mount namespace according to change mount
(/var/lib/snapd/hostfs/usr/share/libreoffice/help /usr/share/libreoffice/help
none bind,ro 0 0): cannot write to
"/var/lib/snapd/hostfs/usr/share/libreoffice/help" because it would affect the
host in "/var/lib/snapd"
update.go:85: cannot change mount namespace according to change mount
(/var/lib/snapd/hostfs/usr/share/sphinx_rtd_theme /usr/share/sphinx_rtd_theme
none bind,ro 0 0): cannot write to
"/var/lib/snapd/hostfs/usr/share/sphinx_rtd_theme" because it would affect the
host in "/var/lib/snapd"
update.go:85: cannot change mount namespace according to change mount
(/var/lib/snapd/hostfs/usr/share/xubuntu-docs /usr/share/xubuntu-docs none
bind,ro 0 0): cannot write to "/var/lib/snapd/hostfs/usr/share/xubuntu-docs"
because it would affect the host in "/var/lib/snapd"
KRB5CCNAME=/tmp/krb5cc_1000
The "will not expose Kerberos ticket's path" is rather interesting, but
it's not clear what 'cmd_run.go' is expecting to see. At some point I
also managed to get:
wtcline@wtcline-desk20:/home/wtcline$ snap run --shell firefox -c
'env|grep KRB'
KRB5CCNAME=FILE:/var/lib/snapd/hostfs/tmp/krb5cc_1000
bash: /usr/libexec/vte-urlencode-cwd: No such file or directory
...which is not a path that I ever specified and has clearly been
transformed by Snap. Any idea what method I should be using to set the
environment variable? Do you see the environment variable in
'about:support'? It seems to differ from what 'snap run --shell
firefox' shows, which is surprising.
Anyways, I tried a bit of fiddling but wasn't able to get Kerberos auth
to work. I even tried manually putting the ticket in the Snap's
sandbox, but it didn't help. Enabling logging still shows the following
error:
[Parent 2504: Main Thread]: D/negotiateauth using REQ_DELEGATE
[Parent 2504: Main Thread]: D/negotiateauth service =
redacted.corporate.com
[Parent 2504: Main Thread]: D/negotiateauth using negotiate-gss
[Parent 2504: Main Thread]: D/negotiateauth entering
nsAuthGSSAPI::nsAuthGSSAPI()
[Parent 2504: Main Thread]: D/negotiateauth Attempting to load gss
functions
[Parent 2504: Main Thread]: D/negotiateauth entering
nsAuthGSSAPI::Init()
[Parent 2504: BgIOThreadPool #2]: D/negotiateauth
nsHttpNegotiateAuth::GenerateCredentials() [challenge=Negotiate]
[Parent 2504: BgIOThreadPool #2]: D/negotiateauth entering
nsAuthGSSAPI::GetNextToken()
[Parent 2504: BgIOThreadPool #2]: D/negotiateauth
gss_init_sec_context() failed: Unspecified GSS failure. Minor code may provide
more information
SPNEGO cannot find mechanisms to negotiate
[Parent 2504: BgIOThreadPool #2]: D/negotiateauth leaving
nsAuthGSSAPI::GetNextToken [rv=80004005]
--
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
