> Any idea what method I should be using to set the environment variable? Do you
> see the environment variable in 'about:support'?
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.
> 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")
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):
--->
# Locate the ticket
% ls /tmp/krb5cc_746400500_DdKFTS
/tmp/krb5cc_746400500_DdKFTS
# Make sure the variable is correctly transformed in the sandbox
% KRB5CCNAME=FILE:/tmp/krb5cc_746400500_DdKFTS snap run --shell firefox -c
'env|grep KRB' KRB5CCNAME=FILE:/var/lib/snapd/hostfs/tmp/krb5cc_746400500_DdKFTS
# Now just launch Firefox and navigate to a place where Kerberos is needed
% KRB5CCNAME=FILE:/tmp/krb5cc_746400500_DdKFTS snap run firefox
<---
> Yet if I set 'KRB5CCNAME=/tmp/krb5cc_1000' in '/etc/environment' and
> reboot then I can get output like the following:
Note KRB5CCNAME must start with the file type, here FILE, so
[INCORRECT] KRB5CCNAME=/tmp/krb5cc_1000
[-CORRECT-] KRB5CCNAME=FILE:/tmp/krb5cc_1000
That is why you saw the "will not expose" error.
> 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
That one is correct, you probably fixed the missing prefix at some point without
noticing.
Now, from what I gather it nonetheless does not work, so let's take a step
back. Can you walk me through the minimal path from boot until your attempt on
Firefox? I.e., do you get a log in screen, you log in with your normal, local
user? Then you generate a ticket with Kinit and then start Firefox with or
without the environment variable?
What is then the output of
id
klist
snap run --shell firefox 'env|grep KRB; id; od ${KRB5CCNAME#FILE:}'
--
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
