Am 04/09/2025 um 19:26 schrieb [email protected]:
> > For some reason it does not show up in about:support, but it is there
> if snap run --shell firefox -c 'env|grep KRB' shows it.
>
> Okay, will keep that in mind.
>
> > I did not know this method. The manual crafting of the environment
> variable works for me (although in my case it already is in the
> environment so I don't really need to do it and am just showing it for
> demonstration's sake):
>
> One of the things I'm finding confusing is trying to distinguish the
> state of the environment variables in the currently running Firefox
> process versus just the current snap command.
You can use /proc/FIREFOX-PID/environ.
> There's also some kind of
> state being set between commands, because the output differs. From a
> fresh boot:
>
> wtcline@wtcline-desk20:~$ KRB5CCNAME=FILE:/tmp/krb5cc_1000 snap run
> --shell firefox -c 'env|grep KRB' 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=FILE:/var/lib/snapd/hostfs/tmp/krb5cc_1000
> wtcline@wtcline-desk20:~$ snap run --shell firefox -c 'env|grep KRB'
> wtcline@wtcline-desk20:~$ snap run --shell firefox -c 'env|grep KRB'
> wtcline@wtcline-desk20:~$ KRB5CCNAME=FILE:/tmp/krb5cc_1000 snap run --shell
> firefox -c 'env|grep KRB'
> KRB5CCNAME=FILE:/var/lib/snapd/hostfs/tmp/krb5cc_1000
> wtcline@wtcline-desk20:~$
The inconsistency there is only the update.go warnings, if I'm reading it right.
That is an old issue, unrelated to the investigation here.
> * kinit
> * KRB5CCNAME=FILE:/tmp/krb5cc_1000 snap run firefox
>
> I believe the above sets up everything correctly. And command output
> (from another shell tab):
> [...]
> wtcline@wtcline-desk20:~$ snap run --shell firefox
> -c 'env|grep KRB; id; od ${KRB5CCNAME#FILE:}'
> uid=1000(wtcline) gid=1000(wtcline)
> groups=1000(wtcline),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),100(users),116(lpadmin)
>
> Note that the environment variable does not appear to be set when
> running the snap command, though it should be set in the process.
The environment variable is indeed not set because I forgot to prepend the
KRB5CCNAME part in the command I wrote for you. Sorry about that.
Anyway, I am able now to reproduce the failure myself with that workflow, even
when passing the ticket via KRB5CCNAME, verifying that the variable gets into
the Firefox' environment and that the ticket that variable points to is
readable from the sandbox.
There must be some difference between
1. Logging in as the Kerberos user (as that is working); and
2. As a local user, passing the ticket generated by Kinit (as that is NOT
working).
Anyway, case 2 could not work out-of-the-box anyway because the environment
variable is not set after Kinit and the Snapd magic relies on that variable. It
still does not explain the failure even after passing the ticket manually, the
library may have some expectations about user running the process and user
encoded in the ticket (if there even is such a thing, speculating here).
For this bug I will set case 2 aside because we do not want to block case 1.
But I'm not disregarding case 2, I will open a bug for it.
--
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
