> You can use /proc/FIREFOX-PID/environ.

Ah, good to know that still works as expected.

> 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.

That's the visible inconsistency, yes, but it shows there's some kind of
hysteresis between the two commands.  My concern would be that the first
command sets state that doesn't get set in the second command.  For
example, if the first command sets up some kind of "environment" and
pulls 'KRB5CCNAME', but only on the first invocation after boot, so if
'KRB5CCNAME' wasn't set for the first command but was set for the second
then 'KRB5CCNAME' would never get pulled.  Hypothetically.  It's the
kind of thing I tend to watch out for when running the same command
unexpectedly gives different results on subsequent runs.

> 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).

Oof.  That's gnarly.

> 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.

Okay, please let me know what the bug ID is.  Thanks again for looking
into this!

-- 
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

Reply via email to