Emergency access fails if grantor doesnt log in during waiting time

[SoleroTG]

Subject of the issue

When the grantee requests access to the grantor's vault, access isn't possible after the wait time if the grantor hasn't logged in during that time. Although the grantee received the Emergency access request for John Doe approved email, the Emergency Access tab of the grantee's account just lists the tags Emergency Access Initiated and View for the grantor user.

Deployment environment

Your environment (Generated via diagnostics page)

• Vaultwarden version: v1.26.0
• Web-vault version: v2022.10.0
• Running within Docker: true (Base: Debian)
• Environment settings overridden: true
• Uses a reverse proxy: true
• IP Header check: true (X-Real-IP)
• Internet access: true
• Internet access via a proxy: false
• DNS Check: true
• Time Check: true
• Domain Configuration Check: true
• HTTPS Check: true
• Database type: SQLite
• Database version: 3.35.4
• Clients used:
• Reverse proxy and version:
• Other relevant information:

Config (Generated via diagnostics page)

Show Running Config

Environment settings which are overridden: DOMAIN, ADMIN_TOKEN, ALLOWED_IFRAME_ANCESTORS, SMTP_HOST, SMTP_SECURITY, SMTP_PORT, SMTP_FROM, SMTP_FROM_NAME, SMTP_USERNAME, SMTP_PASSWORD, SMTP_AUTH_MECHANISM

{
  "_duo_akey": null,
  "_enable_duo": false,
  "_enable_email_2fa": true,
  "_enable_smtp": true,
  "_enable_yubico": true,
  "_icon_service_csp": "",
  "_icon_service_url": "",
  "_ip_header_enabled": true,
  "admin_ratelimit_max_burst": 3,
  "admin_ratelimit_seconds": 300,
  "admin_token": "***",
  "allowed_iframe_ancestors": "*****.******.**",
  "attachments_folder": "data/attachments",
  "authenticator_disable_time_drift": false,
  "data_folder": "data",
  "database_conn_init": "",
  "database_max_conns": 10,
  "database_timeout": 30,
  "database_url": "****/**.*******",
  "db_connection_retries": 15,
  "disable_2fa_remember": true,
  "disable_admin_token": false,
  "disable_icon_download": false,
  "domain": "*****://*****.******.**",
  "domain_origin": "*****://*****.******.**",
  "domain_path": "",
  "domain_set": true,
  "duo_host": null,
  "duo_ikey": null,
  "duo_skey": null,
  "email_attempts_limit": 3,
  "email_expiration_time": 600,
  "email_token_size": 6,
  "emergency_access_allowed": true,
  "emergency_notification_reminder_schedule": "0 5 * * * *",
  "emergency_request_timeout_schedule": "0 5 * * * *",
  "enable_db_wal": true,
  "extended_logging": true,
  "helo_name": null,
  "hibp_api_key": null,
  "icon_blacklist_non_global_ips": true,
  "icon_blacklist_regex": null,
  "icon_cache_folder": "data/icon_cache",
  "icon_cache_negttl": 259200,
  "icon_cache_ttl": 2592000,
  "icon_download_timeout": 10,
  "icon_redirect_code": 302,
  "icon_service": "internal",
  "incomplete_2fa_schedule": "30 * * * * *",
  "incomplete_2fa_time_limit": 3,
  "invitation_expiration_hours": 120,
  "invitation_org_name": "Bitwarden",
  "invitations_allowed": false,
  "ip_header": "X-Real-IP",
  "job_poll_interval_ms": 30000,
  "log_file": null,
  "log_level": "Info",
  "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f",
  "login_ratelimit_max_burst": 10,
  "login_ratelimit_seconds": 60,
  "org_attachment_limit": null,
  "org_creation_users": "*****@******.**",
  "password_hints_allowed": false,
  "password_iterations": 100000,
  "reload_templates": false,
  "require_device_email": false,
  "rsa_key_filename": "data/rsa_key",
  "send_purge_schedule": "0 5 * * * *",
  "sends_allowed": true,
  "sends_folder": "data/sends",
  "show_password_hint": false,
  "signups_allowed": false,
  "signups_domains_whitelist": "******.**,*******.**",
  "signups_verify": true,
  "signups_verify_resend_limit": 6,
  "signups_verify_resend_time": 3600,
  "smtp_accept_invalid_certs": false,
  "smtp_accept_invalid_hostnames": false,
  "smtp_auth_mechanism": "\"Plain\"",
  "smtp_debug": false,
  "smtp_explicit_tls": null,
  "smtp_from": "*******@*****.******.**",
  "smtp_from_name": "Bitwarden",
  "smtp_host": "****.******.**",
  "smtp_password": "***",
  "smtp_port": 465,
  "smtp_security": "force_tls",
  "smtp_ssl": null,
  "smtp_timeout": 15,
  "smtp_username": "******************",
  "templates_folder": "data/templates",
  "tmp_folder": "data/tmp",
  "trash_auto_delete_days": null,
  "trash_purge_schedule": "0 5 0 * * *",
  "use_syslog": false,
  "user_attachment_limit": null,
  "web_vault_enabled": true,
  "web_vault_folder": "web-vault/",
  "websocket_address": "0.0.0.0",
  "websocket_enabled": true,
  "websocket_port": 3012,
  "yubico_client_id": null,
  "yubico_secret_key": null,
  "yubico_server": null
}

Steps to reproduce

1. Create two users grantor and grantee
2. grantor is allowed to create organisations, grantee is not
3. grantor is owner in one group and grantee is user the same group
4. grantor grants grantee View access after one day of waiting
5. grantor logs out of all of his clients
6. grantee request access from grantor
7. grantor does not log in during that waiting time
8. grantee logs in and navigates to Emergency Access after receiving the Emergency access request for grantor approved email
9. the only available option for grantee when clicking the kebab menu is Remove

Expected behaviour

Grantee is able to access grantors vault after the waiting time.

Actual behaviour

Grantee cannot access grantors vault after the waiting time.

[BlackDex]

I have tested this just last week. And it all seems to work fine it looks like.

1. Are you sure the wait time is over?
2. What is the current status in the database? (emergency_access table).

If you are able to, please copy/paste/provide the following columns of the record you think is in error.

• atype
• status
• wait_time_days
• recovery_initiated_at
• last_notification_at
• updated_at
• created_at

Also, please enable LOG_LEVEL=debug, that should provide some more info regarding the jobs running for the emergency access.

Also remember that the wait-time is checked during the scheduled job. That job is executed every hour at minute 5 of that hour.
So, 11:05, 12:05, 13:05 etc... If for example that requested timestamp is 13:06 the previous day, then you will have to wait for 14:05 for that request to be triggered.

Please provide the requested info so that we can try to help.

[SoleroTG]

Thanks for the fast reply.
I tested it twice with a wait time of one hour. I tried to access the grantors vault after I received the email Emergency access request for grantor approved. I didn't wait much longer and reset both accounts afterwards. I run another try and post the results here, as requested.

[BlackDex]

There is no wait time of an hour. There is a minimum of 1day.
So, if you expected it to be one hour, that is mistaken.

[SoleroTG]

Thanks for the correction. I meant one day, of course.

[SoleroTG]

The already active run finished like the ones before.
I received the Emergency access request for grantor approved email at 17:05. Accessing the vault via grantee did not work.
After one and two hours later I still wasn't able to access the vault.

Now I set LOG_LEVEL=debug.

In the emergency_access table in db.sqlite3 I find
atype=0
status=3
wait_time_days=1
recovery_initiated_at=2022-11-18 15:39:15.342045184
last_notification_at=2022-11-18 15:39:15.342045184
updated_at=2022-11-19 18:05:16.410392218
created_at=2022-11-18 15:37:51.165740427

This confuses me as no emergency access is neither active nor pending.

I never messed with the database and just access the db via a offsite copy I took beforehand.

Should I still retry a new emergency access test? I think, that the entry in the emergency_access table situation should be solved before doing so.

[BlackDex]

Strange, it does mention it was updated, but the status is still at 3, which i think from the top of my mind should be 4.

Please enable debug log level, and keep it running. It should keep trying the same, since the status is not correct yet.

[SoleroTG]

Just a small update:
The emergency_access table still shows the same content, although no emergency job being neither active no pending. Should I expect a cronjob fixing the entry?

The only log entries related to this are:

[2022-11-20 01:05:06.664][vaultwarden::api::core::emergency_access][DEBUG] Start emergency_notification_reminder_job
[2022-11-20 01:05:06.664][vaultwarden::api::core::emergency_access][DEBUG] Start emergency_request_timeout_job
[2022-11-20 01:05:06.665][vaultwarden::api::core::emergency_access][DEBUG] No emergency request timeout to approve
[2022-11-20 01:05:06.665][vaultwarden::api::core::emergency_access][DEBUG] No emergency request reminder notification to send

I'm grateful for any advice about what I can or should try next?

[SoleroTG]

Regarding the emergency access I am just getting the above posted entries about no emergency request being active (which is true atm).
The entry in the emergency_access table still exists.

Can I manually delete this entry?

[stefan0xC]

Can I manually delete this entry?

If you remove the grantee as grantor (or yourself as grantee) the entry should be deleted as well.

I'm grateful for any advice about what I can or should try next?

You could try a PRAGMA integrity_check on the sqlite database.

[BlackDex]

If you want to grant your self access by an already approved access, which means ot shared the keys. The you can change the status your self too 4. Else you should also be able to remove the access on either side via the web-vault.

[SoleroTG]

If you remove the grantee as grantor (or yourself as grantee) the entry should be deleted as well.

Right now, no user is shown neither as grantor nor grantee in the ui. This is consistent with my actions in the ui.

You could try a PRAGMA integrity_check on the sqlite database.

I ran the command and received integrity_check OK
The line in the emergency_access table, however, is still there.

The you can change the status your self too 4. Else you should also be able to remove the access on either side via the web-vault.

I changed the status in the emergency_access table from 3 to 4. This made the entry disappear in the db. Looks good so far.

Now I try again to give grantee emergency access and will post the result here.

Thanks for the help. I keep you updated.

[SoleroTG]

It worked.
After I manipulated the db directly and set the status in the emergency_access table from 3 to 4 it worked like a charm.
Although, I have no idea how this corrupt entry appeared in the first place, I am happy that it is working now.

Thanks a lot for the support.

[BlackDex]

Was it corrupted in which sense? Only the state was wrong? Or the database had issues?

As a side note. While i was checking the code, i saw some small enhancements for the code handeling this. I'll see if i can optimize the code a bit and maybe i will encounter something strange that could explain this behaviour.

[BlackDex]

I might have found something which could cause this specific issue.
There could be some race-conditions and that could cause strange behaviors.

[SoleroTG]

Was it corrupted in which sense? Only the state was wrong? Or the database had issues?

The database itself was consistent. With the term corrupted I mean that the database was in a state in which the application didn't function correctly and wasn't able to correct itself. If the term corrupted doesn't fit here I take it back and may as well call it in a funny state.

Anyhow, thanks again for the fast support.

[BlackDex]

To make the terms a bit more clear. A corrupt database is a database which isn't functioning at all.
A record with an invalid state is what was causing the issue.

The reason it is important, a corrupt database could also cause some strange issue, including not being able to update a record.
But, if the database was valid, then there might be a coding issue.

As already mentioned, I think i have found what could cause this. One way of fixing this your self would be to change the schedules of the two emergency access jobs in such a way that they will never run at the same time.

I keep this issue open until i finished the changes to the emergency access code.