'Error: AttributeError' Bug? in HBS3 AWS Glacier due to delete policy needed

Post Reply
rimellJames
First post
Posts: 1
Joined: Mon Feb 10, 2020 5:36 am

'Error: AttributeError' Bug? in HBS3 AWS Glacier due to delete policy needed

Post by rimellJames »

So this looks to be a fundamental bug in the way Glacier Archives are handled by HBS3 (maybe the other versions as well). I was having issues running a backup job for the second time, which had no issues the first time around. Keep in mind I have a policy attached to my IAM backup user that enforces a WORM like pattern - i.e. it has no delete permissions. The UI error of 'Error: AttributeError' is pretty useless, digging into the logs I found the issue

<Response [403]>: {"code":"AccessDeniedException","type":"Client","message":"User: arn:aws:iam::**************:user/************ is not authorized to perform: glacier:DeleteArchive on resource: arn:aws:glacier**************************************:vaults/*************"}

A look a little way back in the stack and it turns out that each time you do the archive it also copies its archive DB file '/QNAPHybridBackupSync_full_4.db' there - clever in a way I guess to ensure the meta data gets stored as well. BUT here is the issue, the first thing it does is try to delete that file (even when there is NO change of files for the backup), I am assuming so it can upload a new copy with any deltas, or maybe it includes the meta data that the job was run but no new data.

So even if you tick the box for one way backup with no delete, your backup user still needs the delete permission in the policy (frankly I really do not like this from a security perspective since if the QNAP box becomes compromised it can run all sorts of havoc with the credentials). I am not sure how this would play with vault locks either. if they changed this to identifiable/dated files, and gave the option to delete old archives on the UI then we could all be more secure.

Also remember though in Glacier once you upload an archive, you have to pay at least 90 days for it - delete it early and you will get a pro-rata cost applied. Hence if you have a nightly backup job, you are effectively have a 90x multiplier on that file. For reference at 245K (243 archive files, not sure of the growth rate hope it is not linear!) = .245Mb * 0.001 * 89 * 0.004 = less than .0001USD so no real cost issue.
riedel
First post
Posts: 1
Joined: Mon May 21, 2018 4:36 pm

Re: 'Error: AttributeError' Bug? in HBS3 AWS Glacier due to delete policy needed

Post by riedel »

Is this behaviour still present? I hesitate to play around with vault policies, to try out myself.

The attack scenario is that the security token of the backup user can be obtained, like in the latest in the latest "walter" incident. IMHO to give decent protection against encryption trojan, a vault lock policy is really needed.

Also it would be great for situation where archiving is needed for compliance.

Is there a way to get this working on HBS3 with S3? Any news. I would be really greatful!
kptSavi
First post
Posts: 1
Joined: Tue Mar 01, 2022 6:26 am

Re: 'Error: AttributeError' Bug? in HBS3 AWS Glacier due to delete policy needed

Post by kptSavi »

I stumbled upon this thread when trying to configure a WORM pattern with Glacier too.

Unfortunately, this behaviour is still present in v19.0.0217.
Post Reply

Return to “Amazon Glacier”