Strange behaviour with encrypted libraries

i’ve just discovered something really puzzling:

  1. i added a new user to my seafile server (6.2.5)
  2. i logged in as that user and added three encrypted libraries (as this was a test, i used the same password for each library)
  3. i then shared these three libraries with two other users
  4. i recognized the desktop clients of both users don’t show the lock on the library icon, and they both could browse the libraries without any password prompt! at that point, the original user had only used the passwords for generating the libraries. when he wanted to open them in the web browser, he was asked for the password.

how is this possible? why is encryption only working for the original user, but not the ones he shares a library with?

1 Like

Weird. Can you please take a look at this @daniel.pan?

I can’t reproduce that. Proceeded exactly as described in the bug report:

  1. created a new user
  2. created three encrypted libraries via the web interface, all with the same password
  3. shared libraries with another user

As expected, the users with whom the library was shared will also be asked for a password. I am currently using CE 6.3.2.

Can you safely reproduce the procedure for yourself? What permissions do the users who create the libraries have? What permissions do the users have with whom was shared? For me, they were both normal users. What is displayed on the web interface for all users? Are the libraries there encrypted? Could the other users only see the file names in the libraries or also the content of the files?

i can reproduce the issue: if i create an ecrypted library with the new user and share it with another, the other user doesn’t see an encrypted library but a normal one. i now used a different passwort, no effect.

i ran a full saef-fsck on the server, nothing popped up. i’d like to rule out a somehow corrupted database – can i check the integrity of the whole database somehow?

as for the other users: if they use the web frontend, the libraries are shown as unencrypted, but they’re prompted for the password when they try to access them.

in the desktop client, however, all shares can be opened in the seafile file browser and it shows the files with correct file names. it is, however, impossible to download files. i just get “error downloading file”.

one other hint: before i created the new libraries, i removed the default “my library”.

the users are all standard users with default permissions.

the issue is also present the other way around. if i add a new encrypted library as an old user and share it with the new one, it is shown as an unencrypted share in his web frontend (i.e., wrong icon) but he get’s asked the password. etc.

however, the user who created the share sees it as encrypted in his own list of libraries, both web and desktop client.

my ccnet.log is full of these:

[07/04/18 13:30:21] ../common/session.c(398): Accepted a local client
[07/04/18 13:30:23] ../common/peer.c(943): Local peer down
[07/15/18 11:38:57] ../common/session.c(398): Accepted a local client
[07/15/18 11:38:58] ../common/peer.c(943): Local peer down
[07/17/18 12:39:04] ../common/session.c(398): Accepted a local client
[07/17/18 12:39:04] ../common/peer.c(943): Local peer down
[07/24/18 22:17:10] ../common/session.c(398): Accepted a local client
[07/24/18 22:17:10] ../common/peer.c(943): Local peer down
[07/25/18 09:58:41] ../common/peer.c(943): Local peer down
[07/25/18 10:08:30] ../common/session.c(398): Accepted a local client
[07/25/18 17:07:34] ../common/session.c(398): Accepted a local client
[07/25/18 17:07:35] ../common/peer.c(943): Local peer down

and my seafile.log is flooded with these messages:

[07/28/2018 02:23:28 PM] size-sched.c(96): Repo size compute queue size is 0
[07/28/2018 02:28:28 PM] size-sched.c(96): Repo size compute queue size is 0
[07/28/2018 02:33:28 PM] size-sched.c(96): Repo size compute queue size is 0
[07/28/2018 02:38:28 PM] size-sched.c(96): Repo size compute queue size is 0
[07/28/2018 02:43:28 PM] size-sched.c(96): Repo size compute queue size is 0
[07/28/2018 02:48:28 PM] size-sched.c(96): Repo size compute queue size is 0
[07/28/2018 02:53:28 PM] size-sched.c(96): Repo size compute queue size is 0
[07/28/2018 02:58:28 PM] size-sched.c(96): Repo size compute queue size is 0
[07/28/2018 03:03:28 PM] size-sched.c(96): Repo size compute queue size is 0
[07/28/2018 03:08:28 PM] size-sched.c(96): Repo size compute queue size is 0
[07/28/2018 03:13:28 PM] size-sched.c(96): Repo size compute queue size is 0
[07/28/2018 03:18:28 PM] size-sched.c(96): Repo size compute queue size is 0
[07/28/2018 03:23:28 PM] size-sched.c(96): Repo size compute queue size is 0
[07/28/2018 03:28:28 PM] size-sched.c(96): Repo size compute queue size is 0

is that something to worry about?

These are no errors. Can you take a video of your screen and show it to us?

i can do screenshots, but not video

Would be fine too.

Okay, that was very helpful. I could reproduce the behavior by entering a 0 in the column is_encrypted in the table RepoInfo in the seafile-db for the corresponding library. Note: However, the file content is always encrypted regardless of this. It is known that the file names are not encrypted.

Why this entry was not set or not correctly read by the client or seahub is now of course the real question.

1 Like

begin with the empty account of user X:

X creates a new encrypted library “testlib”:

X shares the encrypted library with user Y:

he also adds a test file (markdown, but file type doesn’t seem to matter). here i forgot to make a screenshot of the password prompt, but access to the library was only granted after entering the encryption password:

now the spooky part

an here’s where it gets strange. this is what the desktop client of user Y shows after refreshing the list. you can see that there’s no encryption icon for testlib:

Y can open the library with seafile file browser without any password prompt and see the files:
seafile_encryption_issue_2018-07-28_10

when she tries to download the file, however, she only gets an error:


seafile_encryption_issue_2018-07-28_12

but what Y actually can do even without the password is rename files:
seafile_encryption_issue_2018-07-28_13

seafile_encryption_issue_2018-07-28_14

this is now what the library looks like for its owner X:

the file is still intact, no changes to its content.

The metadata is not encrypted, but there seems to be an issue with detecting shared encrypted libraries which is why the client is not asking for the password and the download fails (~file cannot be decrypted).

Which version of the client do you use?

client is 6.1.8 from the ubuntu PPA

one other thing that might (or might not) help debug this:

i noticed this after i got problems with one particular machine (running the 6.1.8 client as well). i created a new encrypted library with ~20GB of photos (~6800 files) and shared it with a user on the other machine. but when the user tried to sync and download the library (where he was actually still asked for the encryption password), the client crashed and did not start again. but as soon as i removed that user from the ones able to access that particular library, his seafile client would start normally again. i was not yet able to fix this issue, but while i tried adding new libraries (to split the large one into smaller chunks), i noticed the strange behaviour described in this thread.

did this one share blow something up?

Sorry for reviving this topic, but it seems the issue is still present, at least I’m experiencing it with Seafile Server 7.0.5 on Raspberry Pi and Windows client 7.0.4 as well as the latest iOS client, both failing to ask for a password and thus not able to download any files.
Furthermore, when I try to sync a shared encrypted library (displayed as non-encrypted) using the Windows client it will crash and also continue to crash after restarting it until I eventually delete the Seafile dir (haven’t tried unsharing it tbh).
To me this is a serious issue and basically renders encrypted libraries unusable as I need them shared.

Am I missing anything or has this issue not been addressed yet?

1 Like

I can confirm your issue with raspberry pi and encrypted libraries.

I can confirm the issue with raspberry pi and encrypted libraries too.

I found this issue: https://github.com/haiwen/seafile/issues/2046