[bug] Removing a user only deactivates the account #727

New issue

Closed

opened 2024-03-31 15:17:10 +00:00 by yukijoou · 2 comments

yukijoou commented

2024-03-31 15:17:10 +00:00

Contributor

Your setup

From source

Extra details

No response

Version

v3.12.1

PostgreSQL version

What were you trying to do?

Deleting a user, through admin-fe or with MIX_ENV=prod mix pleroma.user rm deactivates the account, but never fully removes it.

This is quite problematic, especially for instances running in the EU that have to comply with GDPR.

What did you expect to happen?

The account actually gets deleted

What actually happened?

The account still shows up in MIX_ENV=prod mix pleroma.user list, and the username/email is still taken.

 $ MIX_ENV=prod mix pleroma.user list
<user> moderator: false, admin: false, locked: false, is_active: true
 $ MIX_ENV=prod mix pleroma.user rm <user>
User <user> deleted.
 $ MIX_ENV=prod mix pleroma.user list
<user> moderator: false, admin: false, locked: false, is_active: false

Logs

No response

Severity

I cannot use it as easily as I'd like

Have you searched for this issue?

I have double-checked and have not found this issue mentioned anywhere.

### Your setup From source ### Extra details _No response_ ### Version v3.12.1 ### PostgreSQL version 15 ### What were you trying to do? Deleting a user, through admin-fe or with `MIX_ENV=prod mix pleroma.user rm` deactivates the account, but never fully removes it. This is quite problematic, especially for instances running in the EU that have to comply with GDPR. ### What did you expect to happen? The account actually gets deleted ### What actually happened? The account still shows up in `MIX_ENV=prod mix pleroma.user list`, and the username/email is still taken. ``` $ MIX_ENV=prod mix pleroma.user list <user> moderator: false, admin: false, locked: false, is_active: true $ MIX_ENV=prod mix pleroma.user rm <user> User <user> deleted. $ MIX_ENV=prod mix pleroma.user list <user> moderator: false, admin: false, locked: false, is_active: false ``` ### Logs _No response_ ### Severity I cannot use it as easily as I'd like ### Have you searched for this issue? - [x] I have double-checked and have not found this issue mentioned anywhere.

yukijoou added the

bug

label 2024-03-31 15:17:10 +00:00

Oneric commented

2024-04-02 02:11:58 +00:00

Member

Deleting a user, through admin-fe or with MIX_ENV=prod mix pleroma.user rm deactivates the account, but never fully removes it.

I’m guessing this is done to prevent someone else later registering with the same username. For remote instances (which missed deletes) it’d would look like the same, previous user (since our user AP ids directly use the username) meaning:

retained posts of the previous user are attributed to the new user
they might refuse all new activities of the new user, due to their new key not matching the old publicKey

If a user was deleted by an admin for moderation reasons, keeping the email locked might also be desirable (do we have another way to block signups from certain mail addresses?)

But yeah, all other fields should probably be best cleaned out to not retain any unnecessary personal info.

> Deleting a user, through admin-fe or with MIX_ENV=prod mix pleroma.user rm deactivates the account, but never fully removes it. I’m guessing this is done to prevent someone else later registering with the same username. For remote instances *(which missed deletes)* it’d would look like the same, previous user *(since our user AP ids directly use the username)* meaning: - retained posts of the previous user are attributed to the new user - they might refuse all new activities of the new user, due to their new key not matching the old `publicKey` If a user was deleted by an admin for moderation reasons, keeping the email locked might also be desirable *(do we have another way to block signups from certain mail addresses?)* But yeah, all other fields should probably be best cleaned out to not retain any unnecessary personal info.

Oneric commented

2024-04-13 03:04:55 +00:00

Member

Turns out purging all fields except id, ap_id and nickname is already implemented since ~4 years ago

# https://gdpr.eu/right-to-be-forgotten/

(side note: perhaps it’d be cleaner to remove the user from the db and reinsert with just the intended-to-be-kept rows within one transaction to avoid accidentally forgetting to clear a field, but it also works as is)

I cannot reproduce the described issue with emails; after deleting with mix pleroma.user rm all fields in the DB are cleared and i can signup with the same email again; only the username is now (intentionally) forever unavailable.

The data from pleroma.user list does not contain any personal details, only permissions etc and the unique nickname.

Turns out purging all fields except `id`, `ap_id` and `nickname` is already implemented since ~4 years ago https://akkoma.dev/AkkomaGang/akkoma/src/commit/f8a53fbe2f9cd8bb0db8fce6e9aa06af17366021/lib/pleroma/user.ex#L1794 *(side note: perhaps it’d be cleaner to remove the user from the db and reinsert with just the intended-to-be-kept rows within one transaction to avoid accidentally forgetting to clear a field, but it also works as is)* I cannot reproduce the described issue with emails; after deleting with `mix pleroma.user rm` all fields in the DB are cleared and i can signup with the same email again; only the username is now (intentionally) forever unavailable. The data from `pleroma.user list` does not contain any personal details, only permissions etc and the unique nickname.