Not my file #549
|
Please contact (preferably phone) the Amazon support immediately. |
|
Ok I will call Amazon tomorrow concerning that. It's strange... |
|
Hi, |
|
I would assume that would be some type of Amazon Drive issue and not related to ACD_CLI due to the nature of how it is making federated requests with specific user data. It may behoove you to get debug logs for listings and uploading files to that account to see the auth that is being generated for those requests. Definitely sounds suspicious though. |
|
I will send a mail with evidence to Amazon. I don't know really how works acd_cli but I think it's my API Key which have moved of owner maybe ? |
|
I suspect you got someone else's auth token somehow, but that should never ever happen or even be possible. I would make a backup of your current oauth_data file (maybe that whole acd_cli cache folder it lives in), move it somewhere else, then re-authorize acd_cli. If you still see other people's files, I would raise holy hell with Amazon until they get the message that their authentication system is compromised. If you see someone else's files, it's entirely possible they can see yours. Don't expect much though even if you start seeing your own data again. Amazon Drive has been very flaky since yesterday. |
|
couple days ago I've got the same behaviour using acd_cli |
|
Hi. I suddenly have access to other's files after I deleted the corrupted DB and sync. What the actual fuck?????????? |
|
I have contacted aws-security@amazon.com and security@amazon.com |
|
Ouch. This could be pretty bad. Did you notice any reproducability steps? |
|
@madyoda Nope. It happens very randomly. First your DB somehow gets corrupted. Delete it, |
|
@Saren-Arterius does the amazon web interface show your files? |
|
@madyoda The web interface is fine. Maybe acd_cli triggered this server side problem. |
|
I had exactly the same issue, with the same step to do the bug. |
|
@Saren-Arterius interesting - seems like it's some token thing. Keep us updated re: amazon email(s) |
|
This is most likely a problem with authentication on Amazon's end. Could be really bad if someone, for example, has an automated script backing up their system to a folder called "backup" and it deletes/replaces someone else's backup folder unnoticed after this glitch occurs. Perhaps it's worth adding a basic sanity check to prevent since it's happened to more than just a couple people? Maybe have acd_cli write a uuid to a file on acd_cli or otherwise fingerprint the account to ensure it is using the same account as the last time when it syncs nodes and throw a warning if there is a mismatch? |
|
So this is my take on this: The corrupted db is not the cause of this problem but rather a side effect. I took a look at the authenticator implementation and it seems pretty solid, so maybe amazon screwed something up on their end. I'm currently running a get usage information, renew token, check if usage changed loop to reproduce this error but with no success at this time. |



Hi,
My acd_cli has got a recent database corruption in node.db. I removed it and I executed "acd_cli sync".
But since that moment, I have the files of another person and I can download and see his files, upload and remove files! (Obviously I will not touch his files).
Is there not a problem in acd_cli ?
EDIT: I specify that even I remove the node.db, when I sync I have again the same cloud of this person
Thanks!