files:transfer-ownership command does not work in some scenarios with encryption

[davitol]

Steps to reproduce

1. Create 2 oC users, user1 and user2
2. Log in with user1
3. Create a file.txt
4. Log in as admin user and encrypt the server
5. Log out and log in as admin.
6. As admin via CLI run --> sudo -u www-data ./occ files:transfer-ownership user1 user2

Expected behaviour

The ownership of files should be transferred from user1 to user2

Actual behaviour

An error is shown and some of the files are not transferred

Server configuration

Operating system:
Ubuntu 14.04

Web server:
Apache

Database:
MySQL

PHP version:
5.5.9

ownCloud version:"9.0.1.2","versionstring":"9.0.1 RC2","edition":"Enterprise"}

Updated from an older ownCloud or fresh install:
Fresh

List of activated apps:
Enabled:

• activity: 2.2.1
• admin_audit: 0.7
• comments: 0.2
• dav: 0.1.6
• encryption
• enterprise_key: 0.1.0
• federatedfilesharing: 0.1.0
• federation: 0.0.4
• files: 1.4.4
• files_external: 0.5.2
• files_pdfviewer: 0.8
• files_sharing: 0.9.1
• files_texteditor: 2.1
• files_trashbin: 0.8.0
• files_versions: 1.2.0
• files_videoplayer: 0.9.8
• firewall: 2.3.0
• firstrunwizard: 1.1
• gallery: 14.5.0
• notifications: 0.2.3
• provisioning_api: 0.4.1
• systemtags: 0.2
• templateeditor: 0.1
• updatenotification: 0.1.0
• windows_network_drive: 0.2.33
• workflow: 0.1.3
  Disabled:
• announcementcenter
• external
• files_antivirus
• files_drop
• files_ldap_home
• objectstore
• password_policy
• sharepoint
• user_external
• user_ldap
• user_shibboleth

Are you using external storage, if yes which one: local/smb/sftp/...
No

Are you using encryption:
No

Logs

{"reqId":"U8ld8vodFVW\/2RmfTb3D","remoteAddr":"","app":"PHP","message":"Class 'OC_Mount_Config' not found at \/opt\/owncloud\/apps\/files_external\/appinfo\/register_command.php#38","level":3,"time":"2016-04-04T16:15:31+00:00","method":"--","url":"--","user":"--"}
{"reqId":"JuExhCziPp6jbWEKxrC3","remoteAddr":"","app":"PHP","message":"fclose() expects parameter 1 to be resource, string given at \/opt\/owncloud\/lib\/private\/files\/storage\/wrapper\/encryption.php#748","level":3,"time":"2016-04-04T16:18:07+00:00","method":"--","url":"--","user":"--"}

Client configuration

browser

Firefox

[davitol]

@cmonteroluque @schiesbn

[DeepDiver1975]

We cannot transfer encrypted files and because of that the command should fail.
The encryption status is analysed here - https://github.com/owncloud/core/blob/master/apps/files/command/transferownership.php#L142-L164

@schiesbn any idea why in this case the files are not detected as encrypted? THX

[davitol]

@DeepDiver1975

We cannot transfer encrypted files and because of that the command should fail.

But the encryption was enabled after creating the file ( steps 3 and 4), so this file should not be encrypted, no? Only the ones created after encryption was enabled (no one in this example)

[ghost]

@davitol what does it mean "some of the files" weren't transferred? Anything specific about the ones transferred and the ones not transferred?

[davitol]

@cmonteroluque No. There were 2 skeleton folders and a file.txt in root before encrytion. After the encryption and running the command files:transfer-ownership only 1 skeleton folder was transferred

[DeepDiver1975]

@schiesbn any idea why in this case the files are not detected as encrypted? THX

@schiesbn mind having a look? THX

[schiessle]

No. There were 2 skeleton folders and a file.txt in root before encrytion. After the encryption and running the command files:transfer-ownership only 1 skeleton folder was transferred

OK, folders can't be encrypted. This explains why they where transfered correctly.

any idea why in this case the files are not detected as encrypted? THX

I think the detection works correct. As described by @davitol the file isn't encrypted. The question is: Why does the encryption wrapper still try to decrypt it. I will try it and see if I can find something.

But a even bigger problem I see: Even if we detect correctly that the file isn't encrypted during read we will probably try to encrypt it while writing the file to the new location which of course will fail...But let me try it first.

[schiessle]

I followed the steps provided by @davitol and this was the result:

Which is obvious. According to the test steps user2 never logged-in. So we don't have a public key to encrypt the files for user2. But we don't try to decrypt the file, which is correct because the file is not encrypted.

If I change the steps in this way:

1. Create 2 oC users, user1 and user2
2. Log in with user1
3. Create a file.txt
4. Log in as admin user and encrypt the server
5. Log out and log in as admin.
6. login as user2 (to make sure that user2 has a private and a public key)
7. As admin via CLI run --> sudo -u www-data ./occ files:transfer-ownership user1 user2

Everything works as expected. The file "file.txt" gets transfered together with the skeleton "welcome.txt". BUT there is one independent problem: I can't read the transfered files, I get a "bad signature" error! @LukasReschke once more the signature, can you have a look? Thanks! (tested on 9.0.1)

[schiessle]

@davitol regarding the original issue. Can you re-produce it reliable? Can you double-check that the "file.txt" is not encrypted before you run the occ script? Also check the oc_filecache entry for the file. 'encrypted' should be '0' if the file isn't encrypted.

[DeepDiver1975]

So basically the issue is that user2 was never logged in?
Can we check this case? I'd simply add this as precondition to the transfer command

[davitol]

@schiesbn @DeepDiver1975
Tested again, and the behaviour is like @schiesbn describes in #23786 (comment). So, those steps are not the way to reproduce it.
Btw,

I'd simply add this as precondition to the transfer command

I think it's a good idea

[schiessle]

Can we check this case? I'd simply add this as precondition to the transfer command

Good question. We have some code which does the check as part of the "default encryption module": https://github.com/owncloud/core/blob/master/apps/encryption/lib/keymanager.php#L494

But that's specific to the encryption module, so while you could borrow some code from there this is not really a solution. For a real solution we would probably need something like isReady($user) as part of the encryption Manager in core which could then ask the encryption modules.

[DeepDiver1975]

Let me check if I can make that work ....

[davitol]

Everything works as expected. The file "file.txt" gets transfered together with the skeleton "welcome.txt". BUT there is one independent problem: I can't read the transfered files, I get a "bad signature" error! @LukasReschke once more the signature, can you have a look? Thanks! (tested on 9.0.1)

@schiesbn @DeepDiver1975

Should we file another issue related to this behaviour and close this one via #2400 ?

[PVince81]

@davitol are ALL the transfered files unreadable or only the ones from the skeleton ?

If all transferred files are unreadable then this qualifies as data loss and would become critical, especially if the issue is discovered after the fact at a time where the files cannot be recovered in any way.

[schiessle]

I created here a issue for it: #24095

So let's close this one once #24004 is merged

[jayjlawrence]

I have been bitten by this issue in 10.0.2.1. I thought I had decrypted the user (apprently not). Did a file transfer and now I have encrypted files in one user's account that belong to a different user. No clear path to undo this problem.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.