client causing keyring file to be rewritted every few seconds #1592

madpilot78 · 2019-11-08T11:10:57Z

Expected behaviour

I expect the client to save the credentials when they are actually created or changed and then leave the information as is

Actual behaviour

I have noticed the keyring file is continuously updated, every few seconds. I noticed this because I keep my home directory in sync using unison, here is an excerpt from the log:

UNISON 2.51.2 (OCAML 4.05.0) started propagating changes at 11:59:16.47 on 08 Nov 2019
[BGN] Updating file .local/share/keyrings/Default_keyring.keyring from /usr/home/mad to //micro.madpilot.net//home/mad
[END] Updating file .local/share/keyrings/Default_keyring.keyring
UNISON 2.51.2 (OCAML 4.05.0) finished propagating changes at 11:59:16.48 on 08 Nov 2019
Synchronization complete at 11:59:16  (1 item transferred, 0 skipped, 0 failed)
UNISON 2.51.2 (OCAML 4.05.0) started propagating changes at 11:59:19.37 on 08 Nov 2019
[BGN] Updating file .local/share/keyrings/Default_keyring.keyring from /usr/home/mad to //micro.madpilot.net//home/mad
[END] Updating file .local/share/keyrings/Default_keyring.keyring
UNISON 2.51.2 (OCAML 4.05.0) finished propagating changes at 11:59:19.38 on 08 Nov 2019
Synchronization complete at 11:59:19  (1 item transferred, 0 skipped, 0 failed)
UNISON 2.51.2 (OCAML 4.05.0) started propagating changes at 11:59:24.39 on 08 Nov 2019
[BGN] Updating file .local/share/keyrings/Default_keyring.keyring from /usr/home/mad to //micro.madpilot.net//home/mad
[END] Updating file .local/share/keyrings/Default_keyring.keyring
UNISON 2.51.2 (OCAML 4.05.0) finished propagating changes at 11:59:24.40 on 08 Nov 2019
Synchronization complete at 11:59:24  (1 item transferred, 0 skipped, 0 failed)

From the nextcloud client I found this repeatedly:

[unknown 	static bool LibSecretKeyring::writePassword(const QString &, const QString &, const QString &, const QKeychain::JobPrivate::Mode, const QByteArray &, QKeychain::JobPrivate *)
[OCC::Account::setAppPassword(QString)::(anonymous class)::operator() 	appPassword stored in keychain

This looks like a default behaviour caused by

desktop/src/gui/creds/webflowcredentials.cpp

Line 423 in 5775ec1

_account->setAppPassword(_password);

I'm going to test compiling the client with that line commented out. I understand it's not a permanent fix, but will at least indicate if that line is actually the cause.

Steps to reproduce

1.install
2.connect a nexcloud account

Client configuration

Client version: 2.6.1

Operating system: FreeBSD

OS language: Default (C - english)

Qt version used by client package (Linux only, see also Settings dialog):Qt 5.13.0

Client package (From Nextcloud or distro) (Linux only):FreeBSD nextcloud port updated to latest version

Installation path of client: default, /usr/local/

Server configuration

Nextcloud version:

Storage backend (external storage):

Logs

Please use Gist (https://gist.github.com/) or a similar code paster for longer
logs.

Client logfile: Output of nextcloud --logwindow or nextcloud --logfile log.txt
(On Windows using cmd.exe, you might need to first cd into the Nextcloud directory)
(See also https://docs.nextcloud.com/desktop/2.3/troubleshooting.html#log-files)
Web server error log:
Server logfile: nextcloud log (data/nextcloud.log):

The text was updated successfully, but these errors were encountered:

brrrrrrrt · 2019-11-08T14:42:06Z

using nextcloud-client-2.6.1-2-x86_64 from arch community repo

not sure if this is related, but i experience gnome-keyring-daemon "running amok" with latest version, it consumes lots of cpu, conky reports constantly 20-30M IO write (!!).

i have ~10 Folders "in sync" on 3 different Servers, strange behaviour stops as soon i "stop all synchronizations" and continues if i start it again.

downgrading to V2.6.0 fixes the problem

madpilot78 · 2019-11-08T17:12:06Z

downgrading to V2.6.0 fixes the problem

The line I pointed out comes from this commit: 19491ff

It is four months old, so it was included in 2.6.0 too. But I don't know if this is interacting with something else.

pwfrank · 2019-11-08T19:02:09Z

It is four months old, so it was included in 2.6.0 too. But I don't know if this is interacting with something else.

As far as I can tell, 19491ff was only merged ~3 weeks ago ( #1504 ) and was only just included in the 2.6.1 release https://github.com/nextcloud/desktop/releases/tag/v2.6.1

I'm seeing what seems to be a related issue in which Nextcloud is continually trying to register the Default Keyring in gnome-keyring-daemon. (Arch Linux, nextcloud-client 2.6.1-2 x86_64). Downgrading to 2.6.0 solved the issue for me as well

madpilot78 · 2019-11-09T13:50:44Z

This looks like a default behaviour caused by

desktop/src/gui/creds/webflowcredentials.cpp

Line 423 in 5775ec1

_account->setAppPassword(_password);

I'm going to test compiling the client with that line commented out. I understand it's not a permanent fix, but will at least indicate if that line is actually the cause.

I can now confirm that commenting out the above line in the source code makes tha unwanted behaviour disappear.

I understand this is no fox. It looks like this was added to properly implement the "remote wipe" functionality, and I don't know the details of how that works.

Someone who knows that code should take a better look here.

dkaparis · 2019-11-10T11:03:57Z

using nextcloud-client-2.6.1-2-x86_64 from arch community repo

not sure if this is related, but i experience gnome-keyring-daemon "running amok" with latest version, it consumes lots of cpu, conky reports constantly 20-30M IO write (!!).

i have ~10 Folders "in sync" on 3 different Servers, strange behaviour stops as soon i "stop all synchronizations" and continues if i start it again.

downgrading to V2.6.0 fixes the problem

To add to this, when running nextcloud-client-2.6.1-2-x86_64 on my system, gnome-keyring-daemon entries are continuously spammed in my system log:

gnome-keyring-daemon[774]: asked to register item /org/freedesktop/secrets/collection/login/179, but it's already registered
gnome-keyring-daemon[774]: asked to register item /org/freedesktop/secrets/collection/login/178, but it's already registered
...

Again, V2.6.0 does not exhibit this.

archont00 · 2019-11-12T21:42:48Z

I tried to delete all items in seahorse and re-register nexctloud client again, however, the spamming our system log continued. Downgrading. (Arch Linux).

ldesgrange · 2019-11-18T22:40:34Z

I have a similar issue on macOS (10.13.6) and Nextcloud client 2.6.1. Lots of logs about nextcloud, securityd and Keychain:

Subsystem: com.apple.securityd Category: security_exception	23:26:52.738269 +0100	nextcloud	UNIX error exception: 17
Subsystem: com.apple.securityd Category: policy			23:26:53.328110 +0100	trustd		cert[0]: TemporalValidity =(path)[]> 0
Subsystem: com.apple.securityd Category: SecError		23:26:53.328731 +0100	nextcloud	Trust evaluate failure: [leaf TemporalValidity]
Subsystem: com.apple.securityd Category: security_exception	23:26:55.856622 +0100	securityd	MacOS error: -67050
Subsystem: com.apple.securityd Category: clientid		23:26:55.858304 +0100	securityd	code requirement check failed (-67050), client is not Apple-signed
Subsystem: com.apple.securityd Category: security_exception	23:26:55.862179 +0100	nextcloud	CSSM Exception: -2147413719 CSSMERR_DL_INVALID_UNIQUE_INDEX_DATA
Subsystem: com.apple.securityd Category: integrity		23:26:55.883141 +0100	nextcloud	possible duplicate, trying to delete invalid items
Subsystem: com.apple.securityd Category: integrity		23:26:55.883795 +0100	nextcloud	no unique id, using 6 attributes from mDbAttributes
Subsystem: com.apple.securityd Category: integrity		23:26:55.889692 +0100	nextcloud	duplicate item exception is real; throwing it on
Subsystem: com.apple.securityd Category: security_exception	23:26:55.905105 +0100	securityd	MacOS error: -67050
Subsystem: com.apple.securityd Category: clientid		23:26:55.906420 +0100	securityd	code requirement check failed (-67050), client is not Apple-signed
Subsystem: com.apple.securityd Category: atomicfile		23:26:55.918648 +0100	nextcloud	0x6040010e2700 commited /Users/me/Library/Keychains/login.keychain-db.sb-… to /Users/me/Library/Keychains/login.keychain-db
Subsystem: com.apple.securityd Category: servermode		23:26:55.919807 +0100	securityd	keychain reference in server mode

After a few hours, macOS tells me that Nextcloud clients has written 200GB (!) of data on the hard drive (while only a couple of small text files have been modified).

misch7 · 2019-11-18T23:05:19Z

For Linux:

Did you try the AppImage? Does the error still occur there too?
https://download.nextcloud.com/desktop/releases/Linux/Nextcloud-2.6.1-x86_64.AppImage

For macOS:

@ldesgrange Which build of 2.6.1 did you install?

New release build for macOS 10.12+, notarized by Apple at 2019-11-16:
https://download.nextcloud.com/desktop/releases/Mac/Installer/Nextcloud-2.6.1.20191105.pkg

Legacy build for macOS 10.10 - 10.11 with older Qt and OpenSSL, not notarized (previously used build chain):
https://download.nextcloud.com/desktop/releases/Mac/Installer/Nextcloud-2.6.1.20191104-legacy.pkg

madpilot78 · 2019-11-18T23:41:17Z

For Linux:

Did you try the AppImage? Does the error still occur there too?
https://download.nextcloud.com/desktop/releases/Linux/Nextcloud-2.6.1-x86_64.AppImage

As I stated I'm using FreeBSD and compiling the FreeBSD port. The appimage is not an option for me.

Anyway I did identify the line of code causing this behaviour. I am unable to propose a full patch because I don't know how the remote wipe works. But it definitely needs some change to the line I reference in my first message.

brrrrrrrt · 2019-11-19T02:07:04Z

Did you try the AppImage? Does the error still occur there too?
https://download.nextcloud.com/desktop/releases/Linux/Nextcloud-2.6.1-x86_64.AppImage

yes, just tried and i can confirm, this version shows the exact same behaviour.

pwfrank · 2019-11-19T02:07:26Z

Did you try the AppImage? Does the error still occur there too?

@misch7 I can confirm this issue occurs on the AppImage as well.
Both @madpilot78's workaround in #1592 (comment) and downgrading to 2.6.0 resolve the issue for me

misch7 · 2019-11-19T02:24:15Z

Thanks @brrrrrrrt and @pwfrank ! It's helpful to know, that the issue occurs on the AppImage as well.

And thanks @madpilot78, we'll look into that.

ldesgrange · 2019-11-19T06:24:14Z

@ldesgrange Which build of 2.6.1 did you install?

New release build for macOS 10.12+, notarized by Apple at 2019-11-16:
https://download.nextcloud.com/desktop/releases/Mac/Installer/Nextcloud-2.6.1.20191105.pkg

Yes, I'm using that version: Version 2.6.1stable (build 20191105).

localguru · 2019-11-19T16:07:15Z

Same on Xubuntu 19.10

ii  libnextcloudsync0                     2.6.1-20191017.124538~eoan1          amd64        Nextcloud sync library
ii  nextcloud-client                      2.6.1-20191017.124538~eoan1          amd64        Nextcloud desktop sync client
ii  nextcloud-client-l10n                 2.6.1-20191017.124538~eoan1          all          Nextcloud client internatialization files

localguru · 2019-11-19T17:11:48Z

/etc/rsyslog.d/10-nextcloud_client.conf:

:msg,contains,"asked to register item /org/freedesktop/secrets/collection/login/" ~

JPKCom · 2019-11-22T11:40:09Z

I have the same behavior with version 2.6.1(stable) for macOS.
My macOS version is: 10.14.6 (18G1012)
The client writes approx. 100 GB to the hard disk within approx. 8 hours.
The following messages appear in the log of macOS every 2.5 seconds:

standard    16:04:24.664872 +0100    trustd    asynchronously fetching CRL (http://crl.apple.com/root.crl) for client (nextcloud[420]/0#-1 LF=0)
standard    16:04:24.707079 +0100    nextcloud    CSSM Exception: -2147413719 CSSMERR_DL_INVALID_UNIQUE_INDEX_DATA
standard    16:04:24.708908 +0100    nextcloud    CSSM Exception: -2147413719 CSSMERR_DL_INVALID_UNIQUE_INDEX_DATA
standard    16:04:24.710825 +0100    nextcloud    CSSM Exception: -2147413719 CSSMERR_DL_INVALID_UNIQUE_INDEX_DATA
standard    16:04:24.712520 +0100    nextcloud    possible duplicate, trying to delete invalid items
standard    16:04:24.712882 +0100    nextcloud    no unique id, using 6 attributes from mDbAttributes
standard    16:04:24.717640 +0100    nextcloud    duplicate item exception is real; throwing it on
standard    16:04:24.717718 +0100    nextcloud    caught CssmError during add: -2147413719 CSSMERR_DL_INVALID_UNIQUE_INDEX_DATA
standard    16:04:24.757442 +0100    nextcloud    0x6000035d1880 commited /Users/USER/Library/Keychains/login.keychain-db.sb-ea826489-sQ1OrK to /Users/USER/Library/Keychains/login.keychain-db
standard    16:04:24.779662 +0100    nextcloud    0x6000035d1800 commited /Users/USER/Library/Keychains/login.keychain-db.sb-ea826489-2ZmJPj to /Users/USER/Library/Keychains/login.keychain-db
standard    16:04:24.792280 +0100    trustd    asynchronously fetching CRL (http://crl.apple.com/root.crl) for client (nextcloud[420]/0#-1 LF=0)
standard    16:04:24.819734 +0100    nextcloud    no previous integrity acl exists; making a new one
standard    16:04:24.844267 +0100    nextcloud    0x600003628200 commited /Users/USER/Library/Keychains/login.keychain-db.sb-ea826489-KYw1tL to /Users/USER/Library/Keychains/login.keychain-db

An attempt was made to reinstall the client (2.6.1) over the existing version as well as to completely delete and then reinstall the client (2.6.1). I also logged the client off and logged it back on to the server. This didn't bring any success. Additionally I closed the client, removed all entries from it in the macOS keychain by hand and registered it again on the server. This didn't bring any success either.

The only current solution was a downgrade to client version 2.5.3.

n1ete · 2019-11-22T13:58:42Z

Just want to confirm the same logspam error on an fresh installed & updated Arch Linux. I didnt investigate it for now but can provide logs if needed.

lkrms · 2019-11-23T10:34:23Z

While waiting for this to be fixed and released, can I ask where others are getting 2.6.0 debs from? (assuming you're using deb packages)

I'd prefer not to start using AppImages just for this 🤔

Previous versions (but not 2.6.0) appear here: http://ppa.launchpad.net/nextcloud-devs/client/ubuntu/pool/main/n/nextcloud-client/

So far it looks like I'll need to build it myself or use Debian's repos.

mnlipp · 2019-11-24T12:21:07Z

As the cause has already been analyzed, this is OS independent. Nevertheless, confirmed for nextcloud-client-2.6.1-1.fc30.x86_64 (and I had been so happy that the new version finally appeared in the repos and the annoying update message subsided).

rdica · 2019-11-24T17:13:35Z

Problem confirmed with nextcloud-client-2.6.1-1.fc29.x86_64 as well.

The app password for the remote wipe was constantly being written in WebFlowCredentials::slotFinished to the keychain, leading to unnecessary write and log overhead on the system. This fix introduces a check to only store the app password once in a lifetime of the Account class. Also the method used to store the password will be renamed from setAppPassword to writeAppPasswordOnce to be more expressive. Signed-off-by: Michael Schuster <michael@schuster.ms>

The app password for the remote wipe was constantly being written in WebFlowCredentials::slotFinished to the keychain, leading to unnecessary write and log overhead on the system. This fix introduces a check to only store the app password once in a lifetime of the Account class. Also the method used to store the password will be renamed from setAppPassword to writeAppPasswordOnce to be more expressive. Signed-off-by: Michael Schuster <michael@schuster.ms> (cherry picked from commit dcc84d3) Signed-off-by: Michael Schuster <michael@schuster.ms>

misch7 · 2019-11-30T18:30:39Z

This has been fixed by #1646.

Linux: Please use this AppImage build to test it: #1292 (comment)

The fix will get into the 2.6.2 release.

madpilot78 · 2019-12-01T13:53:48Z

@misch7 Thanks a lot for the fix!

After a quick test I can confirm it works fine on FreeBSD.

pwfrank mentioned this issue Nov 14, 2019

Constant log spam with gnome keyring #1607

Closed

misch7 mentioned this issue Nov 29, 2019

Fix remote wipe keychain storage (issue #1592) #1646

Merged

misch7 mentioned this issue Nov 30, 2019

macOS client constantly writes data and increased cpu usage #1638

Closed

misch7 added this to the 2.6.2 milestone Dec 1, 2019

misch7 self-assigned this Dec 1, 2019

madpilot78 closed this as completed Dec 1, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

client causing keyring file to be rewritted every few seconds #1592

client causing keyring file to be rewritted every few seconds #1592

madpilot78 commented Nov 8, 2019 •

edited

Loading

brrrrrrrt commented Nov 8, 2019 •

edited

Loading

madpilot78 commented Nov 8, 2019

pwfrank commented Nov 8, 2019

madpilot78 commented Nov 9, 2019

dkaparis commented Nov 10, 2019

archont00 commented Nov 12, 2019

ldesgrange commented Nov 18, 2019

misch7 commented Nov 18, 2019

madpilot78 commented Nov 18, 2019

For Linux:

brrrrrrrt commented Nov 19, 2019

pwfrank commented Nov 19, 2019

misch7 commented Nov 19, 2019

ldesgrange commented Nov 19, 2019

localguru commented Nov 19, 2019

localguru commented Nov 19, 2019

JPKCom commented Nov 22, 2019

n1ete commented Nov 22, 2019

lkrms commented Nov 23, 2019

mnlipp commented Nov 24, 2019

rdica commented Nov 24, 2019

misch7 commented Nov 30, 2019 •

edited

Loading

madpilot78 commented Dec 1, 2019 •

edited

Loading

client causing keyring file to be rewritted every few seconds #1592

client causing keyring file to be rewritted every few seconds #1592

Comments

madpilot78 commented Nov 8, 2019 • edited Loading

Expected behaviour

Actual behaviour

Steps to reproduce

Client configuration

Server configuration

Logs

brrrrrrrt commented Nov 8, 2019 • edited Loading

madpilot78 commented Nov 8, 2019

pwfrank commented Nov 8, 2019

madpilot78 commented Nov 9, 2019

dkaparis commented Nov 10, 2019

archont00 commented Nov 12, 2019

ldesgrange commented Nov 18, 2019

misch7 commented Nov 18, 2019

For Linux:

For macOS:

madpilot78 commented Nov 18, 2019

For Linux:

brrrrrrrt commented Nov 19, 2019

pwfrank commented Nov 19, 2019

misch7 commented Nov 19, 2019

ldesgrange commented Nov 19, 2019

localguru commented Nov 19, 2019

localguru commented Nov 19, 2019

JPKCom commented Nov 22, 2019

n1ete commented Nov 22, 2019

lkrms commented Nov 23, 2019

mnlipp commented Nov 24, 2019

rdica commented Nov 24, 2019

misch7 commented Nov 30, 2019 • edited Loading

madpilot78 commented Dec 1, 2019 • edited Loading

madpilot78 commented Nov 8, 2019 •

edited

Loading

brrrrrrrt commented Nov 8, 2019 •

edited

Loading

misch7 commented Nov 30, 2019 •

edited

Loading

madpilot78 commented Dec 1, 2019 •

edited

Loading