Bug 1267534 - kerberos, telepathy: Stopping goa-daemon removes account or expires credentials
kerberos, telepathy: Stopping goa-daemon removes account or expires credentials
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gnome-online-accounts (Show other bugs)
7.2
Unspecified Unspecified
unspecified Severity high
: rc
: ---
Assigned To: Debarshi Ray
Desktop QE
:
Depends On: 1364705
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-30 06:51 EDT by David Jaša
Modified: 2016-11-03 21:03 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-03 21:03:23 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 766733 None None None 2016-05-20 14:39 EDT

  None (edit)
Description David Jaša 2015-09-30 06:51:20 EDT
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 15:39:24 EST
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 13:45:59 EDT
(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 17:53:41 EDT
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 12:27:09 EDT
(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 13:46:37 EDT
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 09:30:15 EDT
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 16:56 EDT
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 17:03 EDT
Created attachment 1187636 [details]
coredump
Comment 16 Matěj Cepl 2016-08-06 06:27:28 EDT
(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 06:41:58 EDT
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 07:44:37 EDT
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 11:21:03 EDT
(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 13:55:31 EDT
(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-03 21:03:23 EDT
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.