From 600f0c1e482ff1f752971f74f8f1689d555ec6af Mon Sep 17 00:00:00 2001 From: Kevin Fenzi Date: Apr 05 2022 09:51:46 +0000 Subject: accountdeletion: update and rework Signed-off-by: Kevin Fenzi --- diff --git a/modules/sysadmin_guide/pages/accountdeletion.adoc b/modules/sysadmin_guide/pages/accountdeletion.adoc index e4db222..e45a409 100644 --- a/modules/sysadmin_guide/pages/accountdeletion.adoc +++ b/modules/sysadmin_guide/pages/accountdeletion.adoc @@ -44,255 +44,21 @@ ticket (who looked, what they saw, etc). Then the account can be disabled.: .... -ssh db02 -sudo -u postgres pqsql fas2 - -fas2=# begin; -fas2=# select * from people where username = 'FOOO'; -.... - -Here you need to verify that the account looks right, that there is only -one match, or other issues. If there are multiple matches you need to -contact one of the main sysadmin-db's on how to proceed.: - +Login to ipa01.iad2.fedoraproject.org +kinit admin@FEDORAPROJECT.ORG +ipa user-disable LOGIN .... -fas2=# update people set status = 'admin_disabled' where username = 'FOOO'; -fas2=# commit; -fas2=# /q -.... - -== Disable Groups - -There is no explicit way to disable groups in FAS2. Instead, we close -the group for adding new members and optionally remove existing members -from it. This can be done from the web UI if you are an administrator of -the group or you are in the accounts group. First, go to the group info -page. Then click the (edit) link next to Group Details. Make sure that -the Invite Only box is checked. This will prevent other users from -requesting the group on their own. - -If you want to remove the existing users, View the Group info, then -click on the View Member List link. Click on All under the Results -heading. Then go through and click on Remove for each member. - -Doing this in the database instead can be quicker if you have a lot of -people to remove. Once again, this requires someone in sysadmin-db to do -the work: - -.... -ssh db02 -sudo -u postgres pqsql fas2 - -fas2=# begin; -fas2=# update group, set invite_only = true where name = 'FOOO'; -fas2=# commit; -fas2=# begin; -fas2=# select p.name, g.name, r.role_status from people as p, person_roles as r, groups as g -where p.id = r.person_id and g.id = r.group_id -and g.name = 'FOOO'; -fas2=# -- Make sure that the list of users in the groups looks correct -fas2=# delete from person_roles where person_roles.group_id = (select id from groups where g.name = 'FOOO'); -fas2=# -- number of rows in both of the above should match -fas2=# commit; -fas2=# /q -.... - -=== User Requested Disables - -According to our Privacy Policy, a user may request that their personal -information from FAS if they want to disable their account. We can do -this but need to do some extra work over simply setting the account -status to disabled. -== Record User's CLA information - -If the user has signed the CLA/FPCA, then they may have contributed -something to Fedora that we'll need to contact them about at a later -date. For that, we need to keep at least the following information: - -* Fedora username -* human name -* email address - -All of this information should be on the CLA email that is sent out when -a user signs up. We need to verify with spot (Tom Callaway) that he has -that record. If not, we need to get it to him. Something like: - -.... -select id, username, human_name, email, telephone, facsimile, postal_address from people where username = 'USERNAME'; -.... - -and send it to spot to keep. - -== Remove the personal information - -The following sequence of db commands should do it: - -.... -fas2=# begin; -fas2=# select * from people where username = 'USERNAME'; -.... - -Here you need to verify that the account looks right, that there is only -one match, or other issues. If there are multiple matches you need to -contact one of the main sysadmin-db's on how to proceed.: - -.... -fas2=# update people set human_name = '', gpg_keyid = null, ssh_key = null, unverified_email = null, comments = null, postal_address = null, telephone = null, facsimile = null, affiliation = null, ircnick = null, status = 'inactive', locale = 'C', timezone = null, latitude = null, longitude = null, country_code = null, email = 'disabled1@fedoraproject.org' where username = 'USERNAME'; -.... - -Make sure only one record was updated: - -.... -fas2=# select * from people where username = 'USERNAME'; -.... - -Make sure the correct record was updated: - -.... -fas2=# commit; -.... - -[NOTE] -.Note -==== -The email address is both not null and unique in the database. Due to -this, you need to set it to a new string for every user who requests -deletion like this. -==== +You can also use the ipa web ui. === Renames -In general, renames do not require as much work as deletions but they -still require coordination. This is because renames do not change the -UID/GID but some of our applications save information based on -username/groupname rather than UID/GID. - -== Rename Accounts - -[WARNING] -.Warning -==== -Needs more eyes. This list may not be complete. -==== - -* Check the databases for koji, pkgdb, and bodhi for occurrences of -the old username and update them to the new username. -* Check fedorapeople.org for home directories and yum repositories under -the old username that would need to be renamed -* Check (or ask the user to check and update) mailing list subscriptions -on fedorahosted.org and lists.fedoraproject.org under the old -username@fedoraproject.org email alias -* Check whether the user has a username@fedoraproject.org bugzilla -account in python-fedora and update that. Also ask the user to update -that in bugzilla. -* If the user is in a sysadmin-* group, check for home directories on -bastion and other infrastructure boxes that are owned by them and need -to be renamed (Could also just tell the user to backup any files there -themselves b/c they're getting a new home directory). -* grep through ansible for occurrences of the username -* Check for entries in trac on fedorahosted.org for the username as an -"Assigned to" or "CC" entry. -* Add other places to check here +For renames, we ask users to create a new account and simply get re-added +to all the groups they were in in the past. There's some discussion about +allowing renames in noggin, but it's not currently implemented. -== Rename Groups - -[WARNING] -.Warning -==== -Needs more eyes. This list may not be complete. -==== -* grep through ansible for occurrences of the group name. -* Check for group-members,group-admins,group-sponsors@fedoraproject.org -email alias presence in any fedorahosted.org or lists.fedoraproject.org -mailing list -* Check for entries in trac on fedorahosted.org for the username as an -"Assigned to" or "CC" entry. -* Add other places to check here - -=== Deletion - -Deletion is the toughest one to audit because it requires that we look -through our systems looking for the UID and GID in addition to looking -for the username and password. The UID and GID are used on things like -filesystem permissions so we have to look there as well. Not catching -these places may lead to security issus should the UID/GID ever be -reused. - -[NOTE] -.Note -==== -Recommended to rename instead When not strictly necessary to purge all -traces of an account, it's highly recommended to rename the user or group -to something like DELETED_oldusername instead of deleting. This avoids -the problems and additional checking that we have to do below. -==== -== Delete Accounts - -[WARNING] -.Warning -==== -Needs more eyes. - -This list may be incomplete. Needs more people to look -at this and find places that may need to be updated. -==== -* Check everything for the #Rename Accounts case. -* Figure out what boxes a user may have had access to in the past. This -means you need to look at all the groups a user may ever have been -approved for (even if they are not approved for those groups now). For -instance, any git*, svn*, bzr*, hg* groups would have granted access to -hosted03 and hosted04. packager would have granted access to -pkgs.fedoraproject.org. Pretty much any group grants access to -fedorapeople.org. -* For those boxes, run a find over the files there to see if the UID -owns any files on the system: -+ -.... -# find / -uid 100068 -print -.... -+ -Any files owned by that uid must be reassigned to another user or:: - removed. - -[WARNING] -.Warning -==== -What to do about backups? Backups pose a special problem as they may -contain the uid that's being removed. Need to decide how to handle this. -==== -* Add other places to check here - -== Delete Groups - -[WARNING] -.Warning -==== -Needs more eyes. - -This list may be incomplete. Needs more people to look -at this and find places that may need to be updated. -==== -* Check everything for the #Rename Groups case. -* Figure out what boxes may have had files owned by that group. This -means that you'd need to look at the users in that group, what boxes -they have shell accounts on, and then look at those boxes. groups used -for hosted would also need to add hosted03 and hosted04 to that list and -the box that serves the hosted mailing lists. -* For those boxes, run a find over the files there to see if the GID -owns any files on the system: -+ -.... -# find / -gid 100068 -print -.... -+ -Any files owned by that GID must be reassigned to another group or -removed. +=== Delete or GDPR requests -[WARNING] -.Warning -==== -What to do about backups? Backups pose a special problem as they may -contain the gid that's being removed. Need to decide how to handle this. -==== -* Add other places to check here +Users making GDPR delete or personal data requests should file a ticket at +https://pagure.io/fedora-pdr/ for processing. Thats out of the scope +of this SOP.