Attached is a v2 debdiff for kinetic. Again, minor changes, corrected
version, dep3 tags.

** Patch added: "debdiff for tracker-miners on kinetic"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5663489/+files/lp1779890_kinetic_v2.debdiff

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1779890

Title:
  gvfsd process does not have the KRB5CCNAME environment set

Status in gvfs package in Ubuntu:
  New
Status in tracker-miners package in Ubuntu:
  Fix Released
Status in gvfs source package in Bionic:
  New
Status in tracker-miners source package in Bionic:
  Won't Fix
Status in gvfs source package in Focal:
  New
Status in tracker-miners source package in Focal:
  In Progress
Status in gvfs source package in Jammy:
  New
Status in tracker-miners source package in Jammy:
  In Progress
Status in gvfs source package in Kinetic:
  New
Status in tracker-miners source package in Kinetic:
  In Progress
Status in gvfs source package in Lunar:
  New
Status in tracker-miners source package in Lunar:
  Fix Released

Bug description:
  [ Impact ]

  The KRB5CCNAME environment variable points to the Kerberos ticket of
  the current machine and this ticket is used for authentication in
  Active Directory  servers.

  This variable is set by pam_sss when the user authenticates and can be
  used by other processes, such as gio, to skip the credentials input
  when accessing network shares, for example.

  Some services rely on gvfs-daemon in order to properly function, such
  as tracker-extract-3.service and tracker-miner-fs-3.service, which
  means they will ask for the gvfs-daemon to be initialized when they
  are executed by systemd. This creates problems if one service that
  relies on gvfsd is started too early, as it would result in gvfsd
  being started too early as well.

  As of version 3.1 of tracker-miners, the install target of tracker-
  miners-fs-3.service was set to gnome-session.target:
  https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/283

  However, the tracker-extract-3.service was not updated and its target
  is still default.target, which is too early for the service to start.

  Starting tracker-extract too early is also starting gvfsd too early,
  before the session environment gets fully updated. Which means that
  gvfsd does not have the KRB5CCNAME variable and can not do any
  operations with it.

  Tracker-extract is supposed to be a helper service managed by tracker-
  miner-fs-3.service. By using a [Install] section, we are actually
  telling systemd that it should manage this service as well, when it
  shouldn't.

  So, by removing the [Install] section and having tracker-miner-
  fs-3.service being tied to gnome-session.target, we fix the issue of
  gvfsd starting too early without the updated session environment.

  [ Test Plan ]

  In order to test this issue, it's required to have an Active Directory server 
running.
  1) Authenticate with an AD user (as this would set the KRB5CCNAME env);
  2) Check gvfsd environment. This can be done by running:
      cat /proc/$(pidof gvfsd)/environ | xargs --null -n1

     You will be able to see that it does not have the variable listed.
  3) Check that the information mentioned above about tracker-miner-fs-
     3.service is true.
  4) Disable tracker-extract-3.service (This is a bit tricky, since its
     target was default.target. The easiest way is to remove the symlink that
     systemd created when enabling the unit, located under
     /etc/systemd/user/default.target.wants/tracker-extract-3.service
  5) Reboot the machine;
  6) Repeat steps 1 and 2.
     This will show that gvfsd is now started with the proper environment.

  Is not enough to look at ptree and the pids of the processes, instead
  it's better to look into the session logs with:

     journalctl --user -b

  And check the order in which the services were started and when they
  were triggered.

  Test packages are available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf320070-test

  After installing test packages of tracker-miners, KRB5CCNAME should be
  set in gvfs environment upon login to gnome.

  [ Where problems could occur ]

  The tracker project is a search engine that speeds up search
  operations in Gnome. The tracker-miners is the indexing daemon that
  populates the database with information, so changing its start does
  not affect the system behavior.

  This changes fix the startup of gvfs-daemon.service, which could delay
  services that relied on it running to be executed.

  [ Other info ]

  This was fixed upstream by the following commit:

  commit 29a2320c1e4f0f7ced3c3e9d4d1c06c51518c1f3
  From: Denison Barbosa <denison.barb...@canonical.com>
  Date: Tue, 21 Mar 2023 15:04:28 +0000
  Subject: Removing [Install] section from tracker-extract-3.service
  Link: 
https://gitlab.gnome.org/GNOME/tracker-miners/-/commit/29a2320c1e4f0f7ced3c3e9d4d1c06c51518c1f3

  Focal requires three additional patches to solve the issue, namely:

  commit 8065985c8d818414a36fe151862afdf42c5eda8a
  Author: Laurent Bigonville <bi...@bigon.be>
  Date: Sat, 4 Apr 2020 19:18:00 +0200
  Subject: Move the Install section to the systemd .service file instead
   of the udev one
  Link: 
https://gitlab.gnome.org/GNOME/tracker-miners/-/commit/8065985c8d818414a36fe151862afdf42c5eda8a

  commit 74ae33ce01b8d314d6e33746915f75f270b0e21d
  Author: Sam Thursfield <s...@afuera.me.uk>
  Date: Tue, 3 Nov 2020 12:50:02 +0100
  Subject: miners: Opt out of systemd / XDG autostart integration
  Link: 
https://gitlab.gnome.org/GNOME/tracker-miners/-/commit/74ae33ce01b8d314d6e33746915f75f270b0e21d

  commit 3a75f93865e8eb002a377a341a72b1a4b22a8040
  Author: Sam Thursfield <s...@afuera.me.uk>
  Date: Tue, 27 Oct 2020 22:05:07 +0100
  Subject: miners: Tie systemd startup to gnome-session.service
  Link: 
https://gitlab.gnome.org/GNOME/tracker-miners/-/commit/3a75f93865e8eb002a377a341a72b1a4b22a8040

  
  ## Original description ##
  Nautilus prompts for username and password when accessing a Samba share on a 
network drive, despite having a perfectly valid unexpired Kerberos ticket. The 
Kerberos ticket is obtained automatically at logon by authentication against a 
Samba Active Directory server (Samba AD-DC).

  Accessing the same Samba share with the same Kerberos ticket via
  "smbclient //host/sharename -k" works fine.

  One known workaround is: "nautilus -q", and then "killall gvfsd".
  After that, accessing the Samba share with Nautilus works normally as
  it should.

  I did not experience this issue in Ubuntu 16.04. It appears that a
  regression was introduced somewhere between 16.04 and 18.04.

  The issue is quite annoying and confusing for the users who are used
  to accessing Samba shares on the network drive without being prompted
  for their username and password.

  The issue appears to manifest itself usually not on the first access
  to a Samba share, but on subsequent accesses after a system reboot or
  upon user logout/login. Strangely, removing ~/.cache/ibus/bus/registry
  file before user login appears to fix the issue for the current user
  session, but then the problem reappears upon subsequent user logins or
  after a system reboot.

  Nemo appears to have the same problem as Nautilus.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1779890/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to     : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to