How to change ownership of password


#1

Hi, I am stuck in the following situation.

  • Someone has left the organisation, and I want to delete the user. I don’t have their private key.
  • When I try to delete the user, it says I cannot because there are three passwords of which they are the sole owner
  • I have the “Admin” role. I am also a member of a group which two of those three passwords are accessible to.
  • When I go to one of those two passwords and select the Share tab, I can see:

Some Group [can update] (X)
Left Person [is owner] (X)

  • However I can see no way to add a new owner, nor change the status of either item (the drop-down is greyed out), nor delete either entry (the (X) button has no effect)

I found these previous posts:
https://github.com/passbolt/passbolt_api/issues/133 (closed)
As an admin, while deleting a user who is the sole owner of a password that is shared, I should be able to transfer the ownership to another user in order to be able to perform the deletion

Assuming that the feature is not implemented, is there a documented way to get out of this situation via direct SQL manipulation?

Supplementary question: I’m not entirely clear about the capabilities granted to password “owner”, versus system “admin”. If this is documented somewhere, can you point me to it?

I am guessing that an “admin” can create new users, but only the password “owner” can decide who it is shared with. If so, I presume this distinction is so that admins cannot add sharing rights to themselves to see any stored password.

However, you will note that in the case of two of the three passwords, I already have rights to see and edit the passwords (by virtue of my membership of another group which the password was shared with).

In that case: perhaps it would be reasonable that an Admin who already has read or update access to a particular password, should gain Ownership rights to it (i.e. be able to modify the sharing rights). Does that make sense?

Many thanks,

Brian.


#2

Hi,

The github story you mentioned has already been moved in this forum: As an admin, while deleting a user who is the sole owner of a password that is shared, I should be able to transfer the ownership to another user in order to be able to perform the deletion

There is no documented turn-around as of now. The SQL manipulations can be quite complicated since it would deal directly with the permissions table, and because it has to be mentioned: I wouldn’t recommend any direct SQL manipulation in the passbolt database as it can lead to non desired side effects. However, if really you are stuck let’s try something. What we could do through sql here is:
(BEFORE ANYTHING DON’T FORGET TO DO A BACKUP OF YOUR DATABASE).

  1. set the group as a second owner of the password.
    UPDATE permissions SET type=15 WHERE aco_foreign_key='{resource_uuid}' AND aro_foreign_key='{group_uuid}'
    type=15 means owner permission.

  2. If you have identified which is the third password that is shared with another user, then you could set the other user the password is shared with as an admin, similarly to what we did above:
    UPDATE permissions SET type=15 WHERE aco_foreign_key='{resource_uuid}' AND aro_foreign_key='{user_uuid}'

If you manage to do #1 and #2, then you should be able to delete the user from the UI without being blocked.

If you are unable to do #2 for some reason, and if that third password is not important to you, then you can ignore it and delete the user directly in db.
UPDATE users SET deleted=1 WHERE id={user_uuid}

Let me know if that works.

Regarding your question about the admin privileges, our take is that an admin should normally not have more access rights to the passwords than the ones given to him by the other users while sharing them (It can be argued, feel free to post a separate thread on this forum if you wish to start a discussion). However, there are specific circumstances (such as during a password deletion) for which a bypass can be necessary, since it impacts the capabilities of the admin to manage the users. Hence, the compromise we are willing to make here is to give the admin extra privileges only when these specific scenarios occur so that he can do his job without being blocked by the system.

Cheers, and good luck!
Kevin


#3

Yes thank you! I identified the affected resources, updated the permissions so that all the other users or groups who had permissions on those resources were upgraded to Owner:

mysql> select type from permissions where aco='Resource' and aco_foreign_key in ('59fc94b8-5670-45db-bd15-32f2b92d621e', '5a02ce63-5b9c-43f8-ace6-066ab92d621e', '5a02ced7-3e1c-49c6-b60b-11e
+------+
| type |
+------+
|   15 |
|    7 |
|    7 |
|    7 |
|   15 |
|    7 |
|   15 |
|    7 |
+------+
8 rows in set (0.00 sec)

mysql> update permissions set type=15 where aco='Resource' and aco_foreign_key in ('59fc94b8-5670-45db-bd15-32f2b92d621e', '5a02ce63-5b9c-43f8-ace6-066ab92d621e', '5a02ced7-3e1c-49c6-b60b-11e
Query OK, 5 rows affected (0.14 sec)
Rows matched: 8  Changed: 5  Warnings: 0

… and then the GUI let me delete the user.

Yep, I will do that.

Thanks again,

Brian.


opened #5

#6

Discussion moved to Understanding the Passbolt rights model