RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1267534 - kerberos, telepathy: Stopping goa-daemon removes account or expires credentials
Summary: kerberos, telepathy: Stopping goa-daemon removes account or expires credentials
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gnome-online-accounts
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Debarshi Ray
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On: 1364705
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-09-30 10:51 UTC by David Jaša
Modified: 2016-11-04 01:03 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-04 01:03:23 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
backtrace (5.01 KB, text/plain)
2016-08-04 20:56 UTC, Matěj Cepl 		no flags Details
coredump (1.70 MB, application/x-bzip2)
2016-08-04 21:03 UTC, Matěj Cepl 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 766733 0 Normal RESOLVED kerberos, telepathy: Stopping goa-daemon removes account or expires credentials 2020-01-21 12:23:52 UTC
Red Hat Product Errata RHBA-2016:2223 0 normal SHIPPED_LIVE gnome-online-accounts bug fix update 2016-11-03 13:26:02 UTC

Description David Jaša 2015-09-30 10:51:20 UTC 
Description of problem:
I need to re-run goa-daemon in order to catch some bug. Annoying side-effects are however:
  * expired kerberos credential (kerberos configured outside of GOA)
  * removed Jabber accounts when empathy is running


Version-Release number of selected component (if applicable):
gnome-online-accounts-3.14.4-3.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1. log in to gnome session
2. kinit user@REALM
3. set up jabber account in GOA, run empathy
4. G_MESSAGES_DEBUG=all /usr/libexec/goa-daemon --replace

Actual results:
  * kerberos credential are expired
  * jabber/gabble account is marked as stale and removed

Expected results:
accounts aren't touched at all during --replace

Additional info:
Comment 1 Andrew Dingman 2015-12-15 20:39:24 UTC 
This bug exists on Fedora 23 as of today as well, at least for Kerberos credentials. I don't have Jabber accounts configured that way.
Comment 7 Debarshi Ray 2016-05-18 17:45:59 UTC 
(In reply to Andrew Dingman from comment #1)
> This bug exists on Fedora 23 as of today as well, at least for Kerberos
> credentials.

While I failed to reproduce it both on Fedora 23 and 21 (should be similar to RHEL 7.2), I could reproduce it on a CentOS 7.2 VM. Interesting.

Does it work for you with the latest batch of updates (say gnome-online-accounts-3.18.4-1.fc23.x86_64) on Fedora 23?
Comment 8 Andrew Dingman 2016-05-18 21:53:41 UTC 
I just tried on a fully updated F23 laptop, and goa-daemon --replace deleted my Kerberos credential cache.
Comment 10 Debarshi Ray 2016-05-19 16:27:09 UTC 
(In reply to Debarshi Ray from comment #7)
> (In reply to Andrew Dingman from comment #1)
> > This bug exists on Fedora 23 as of today as well, at least for Kerberos
> > credentials.
> 
> While I failed to reproduce it both on Fedora 23 and 21 (should be similar
> to RHEL 7.2), I could reproduce it on a CentOS 7.2 VM. Interesting.
> 
> Does it work for you with the latest batch of updates (say
> gnome-online-accounts-3.18.4-1.fc23.x86_64) on Fedora 23?

(In reply to Andrew Dingman from comment #8)
> I just tried on a fully updated F23 laptop, and goa-daemon --replace deleted
> my Kerberos credential cache.

I am able to reliably reproduce it on Fedora 23 today. Makes me think that there is a race somewhere.

Anyway, I understand what is going on here. I will dump my thoughts shortly.
Comment 11 Debarshi Ray 2016-05-19 17:46:37 UTC 
When goa-daemon is restarted (and the older daemon dies) all GoaClient instances emit account-removed. Both GoaTpAccountLinker and GoaIdentityService mistake this emission as an explicit user action to delete the account. They probably shouldn't do that.

This is somewhat documented [1] and recommended against:
"... must not destroy data if an account object is removed (e.g. when the “account-removed” signal is emitted) - for example, if the goa-daemon program crashes or is restarted on software upgrade, account objects will be removed only to be added back the next time goa-daemon is started."

[1] https://developer.gnome.org/goa/stable/overview-writing.html
Comment 12 Debarshi Ray 2016-06-13 13:30:15 UTC 
I have built gnome-online-accounts-3.14.5-3.el7:
https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=11171050
Comment 14 Matěj Cepl 2016-08-04 20:56:45 UTC 
Created attachment 1187635 [details]
backtrace

When running

/usr/libexec/goa-daemon --replace

and flipping status of the Kerberos account in the GOA panel, goa-daemon crashed.
Comment 15 Matěj Cepl 2016-08-04 21:03:29 UTC 
Created attachment 1187636 [details]
coredump
Comment 16 Matěj Cepl 2016-08-06 10:27:28 UTC 
(In reply to Matěj Cepl from comment #15)
> Created attachment 1187636 [details]
> coredump

bug 1364705 for the crash filed
Comment 17 Matěj Cepl 2016-08-06 10:41:58 UTC 
True, kerberos credentials are not expired and jabber account is not marked stale and removed. When the crash in goa-daemon is resolved, this can be marked as VERIFIED.
Comment 18 Matěj Cepl 2016-08-13 11:44:37 UTC 
With gnome-online-accounts-3.14.5-4.el7.x86_64 we are unfortunately back in the square one: nothning crashes, but I loose all credentials:

matej@mitmanek: ~$ /usr/libexec/goa-daemon --replace
goa-daemon-Message: goa-daemon version 3.14.5 starting

(goa-daemon:4481): goa-daemon-WARNING **: Unsupported account type (null) for ID account_1431980557_4 (no provider)

(goa-daemon:4481): tp-glib-CRITICAL **: tp_proxy_add_interface_by_id: assertion 'tp_proxy_get_invalidated (self) == NULL' failed

(goa-daemon:4481): tp-glib-CRITICAL **: tp_proxy_add_interface_by_id: assertion 'tp_proxy_get_invalidated (self) == NULL' failed

(goa-daemon:4481): tp-glib-CRITICAL **: tp_proxy_add_interface_by_id: assertion 'tp_proxy_get_invalidated (self) == NULL' failed

(goa-daemon:4481): tp-glib-CRITICAL **: tp_proxy_add_interface_by_id: assertion 'tp_proxy_get_invalidated (self) == NULL' failed

(goa-daemon:4481): tp-glib-CRITICAL **: tp_proxy_add_interface_by_id: assertion 'tp_proxy_get_invalidated (self) == NULL' failed

(goa-daemon:4481): tp-glib-CRITICAL **: tp_proxy_add_interface_by_id: assertion 'tp_proxy_get_invalidated (self) == NULL' failed
** Message: received an invalid or unencryptable secret

(goa-daemon:4481): GoaBackend-WARNING **: secret_password_lookup_sync() returned NULL
goa-daemon-Message: /org/gnome/OnlineAccounts/Accounts/account_1459786313_0: Setting AttentionNeeded to TRUE because EnsureCredentials() failed with: No credentials found in the keyring (goa-error-quark, 4)
** Message: received an invalid or unencryptable secret

(goa-daemon:4481): GoaBackend-WARNING **: secret_password_lookup_sync() returned NULL
goa-daemon-Message: /org/gnome/OnlineAccounts/Accounts/account_1444367638_0: Setting AttentionNeeded to TRUE because EnsureCredentials() failed with: No credentials found in the keyring (goa-error-quark, 4)
** Message: received an invalid or unencryptable secret

(goa-daemon:4481): GoaBackend-WARNING **: secret_password_lookup_sync() returned NULL
** Message: received an invalid or unencryptable secret

(goa-daemon:4481): GoaBackend-WARNING **: secret_password_lookup_sync() returned NULL
** Message: received an invalid or unencryptable secret

(goa-daemon:4481): GoaBackend-WARNING **: secret_password_lookup_sync() returned NULL
** Message: received an invalid or unencryptable secret

(goa-daemon:4481): GoaBackend-WARNING **: secret_password_lookup_sync() returned NULL
goa-daemon-Message: /org/gnome/OnlineAccounts/Accounts/account_1453141725_1: Setting AttentionNeeded to TRUE because EnsureCredentials() failed with: No credentials found in the keyring (goa-error-quark, 4)

(goa-daemon:4481): goa-daemon-WARNING **: Unsupported account type (null) for ID account_1431980557_4 (no provider)

(goa-daemon:4481): goa-daemon-WARNING **: Unsupported account type (null) for ID account_1431980557_4 (no provider)

(goa-daemon:4481): goa-daemon-WARNING **: Unsupported account type (null) for ID account_1431980557_4 (no provider)
** Message: received an invalid or unencryptable secret

(goa-daemon:4481): GoaBackend-WARNING **: secret_password_lookup_sync() returned NULL
** Message: received an invalid or unencryptable secret

(goa-daemon:4481): GoaBackend-WARNING **: secret_password_lookup_sync() returned NULL

(goa-daemon:4481): GoaBackend-WARNING **: secret_password_lookup_sync() returned NULL
** Message: received an invalid or unencryptable secret

(goa-daemon:4481): GoaBackend-WARNING **: secret_password_lookup_sync() returned NULL
** Message: received an invalid or unencryptable secret

(goa-daemon:4481): GoaBackend-WARNING **: secret_password_lookup_sync() returned NULL
** Message: received an invalid or unencryptable secret

(goa-daemon:4481): GoaBackend-WARNING **: secret_password_lookup_sync() returned NULL
** Message: received an invalid or unencryptable secret

(goa-daemon:4481): GoaBackend-WARNING **: secret_password_lookup_sync() returned NULL
** Message: received an invalid or unencryptable secret

(goa-daemon:4481): GoaBackend-WARNING **: secret_password_lookup_sync() returned NULL
** Message: received an invalid or unencryptable secret

(goa-daemon:4481): GoaBackend-WARNING **: secret_password_lookup_sync() returned NULL
** Message: received an invalid or unencryptable secret

(goa-daemon:4481): GoaBackend-WARNING **: secret_password_lookup_sync() returned NULL
** Message: received an invalid or unencryptable secret

(goa-daemon:4481): GoaBackend-WARNING **: secret_password_lookup_sync() returned NULL
** Message: received an invalid or unencryptable secret

(goa-daemon:4481): GoaBackend-WARNING **: secret_password_lookup_sync() returned NULL
** Message: received an invalid or unencryptable secret

(goa-daemon:4481): GoaBackend-WARNING **: secret_password_lookup_sync() returned NULL
matej@mitmanek: ~$
Comment 19 Debarshi Ray 2016-08-19 15:21:03 UTC 
(In reply to Matěj Cepl from comment #18)
> With gnome-online-accounts-3.14.5-4.el7.x86_64 we are unfortunately back in
> the square one: nothning crashes, but I loose all credentials:

The crash in bug 1364705 is orthogonal to this bug. You could have crashed it before if you toggled the switch at precisely the right time. ie. while it was refreshing the Kerberos ticket. Starting goa-daemon is one of those times when it does a refresh.

FWIW, normally, goa-daemon is started by evolution-data-server when the user logs in. It is extremely hard to toggle the switch unless someone is trying to debug something and manually restarts the daemon. Even then, toggling the switch during the startup is a bit of a pathological case.

So, I think we can ignore bug 1364705 (it seems to be fixed anyway), and concentrate on this one. :)

Regarding the issue of Kerberos and Telepathy accounts being affected by a goa-daemon restart, here is how I test it:

(a) Install new RPM
(b) Restart gnome-session (ie. log out/in), or
    Restart /usr/libexec/goa-identity-service - just executing the binary is enough
(c) Ensure that I have a Kerberos and a Telepathy account for testing
(d) /usr/libexec/goa-daemon --replace

I tried this again on a RHEL 7.2 system with gnome-online-accounts-3.14.5-4.el7.x86_64 and it works as expected. I suspect that you didn't restart goa-identity-service.
Comment 21 Matěj Cepl 2016-08-31 17:55:31 UTC 
(In reply to Debarshi Ray from comment #19)
> I tried this again on a RHEL 7.2 system with
> gnome-online-accounts-3.14.5-4.el7.x86_64 and it works as expected. I
> suspect that you didn't restart goa-identity-service.

Yes, most likely. Thanks.
Comment 23 errata-xmlrpc 2016-11-04 01:03:23 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2223.html
Note You need to log in before you can comment on or make changes to this bug.