Greetings.
I thought I would bring up for dicussion here something thats come up after the new account system has been put in place.
Namely, how do we handle group deletions. In the FAS2 world, we never deleted anything. I think this was partly due to an over abundence of caution (there could be files owned by the group left over on various machines) and partly just because it was easier.
We now have 5 requests to remove various no longer used groups.
I've enabled audit logging on our ipa01 instance, so we have audit logs (and I intend to back them up and keep them forever). So we can tell when a group was deleted by whom. We also have a db dump from fas2 before the switchover where we can look at who was in what group or what created it.
So, I would like to propose:
* we will remove groups on request/ticket from a group manager. * we will not seek out groups to remove, as them being there doesn't really hurt anything.
Thoughts?
If there's no objections soon I will go ahead and process those requests.
kevin
On Mon, Apr 19, 2021 at 2:36 PM Kevin Fenzi kevin@scrye.com wrote:
So, I would like to propose:
- we will remove groups on request/ticket from a group manager.
Should there be an announcement or at least a ping of other group managers just to make sure there are no objections? While unlikely, I'm a little concerned that a rogue group manager could cause some harm on their way out the door, for example.
- we will not seek out groups to remove, as them being there doesn't
really hurt anything.
That makes sense.
On Mon, Apr 19, 2021 at 02:43:58PM -0400, Ben Cotton wrote:
On Mon, Apr 19, 2021 at 2:36 PM Kevin Fenzi kevin@scrye.com wrote:
So, I would like to propose:
- we will remove groups on request/ticket from a group manager.
Should there be an announcement or at least a ping of other group managers just to make sure there are no objections? While unlikely, I'm a little concerned that a rogue group manager could cause some harm on their way out the door, for example.
Yeah, I considered that... but if they do, we could always recreate the group and re-add people I would think.
kevin
Should there be an announcement or at least a ping of other group managers just to make sure there are no objections? While unlikely, I'm a little concerned that a rogue group manager could cause some harm on their way out the door, for example.
I think a good solution for this would be needing +1s on the ticket from group members before it can be deleted, with a few possible exceptions of old groups with only 1 or 2 people in them.
We now have 5 requests to remove various no longer used groups.
I've enabled audit logging on our ipa01 instance, so we have audit logs (and I intend to back them up and keep them forever). So we can tell when a group was deleted by whom. We also have a db dump from fas2 before the switchover where we can look at who was in what group or what created it.
So, I would like to propose:
- we will remove groups on request/ticket from a group manager.
- we will not seek out groups to remove, as them being there doesn't
really hurt anything.
Thoughts?
Otherwise I think if we have the audit log then we should be free to delete the groups as needed. It will likely be a rare request in future, the new account system has triggered a spring clean I think.
Mark
On Tue, Apr 20, 2021 at 7:27 PM Mark O'Brien markobri@redhat.com wrote:
Should there be an announcement or at least a ping of other group managers just to make sure there are no objections? While unlikely, I'm a little concerned that a rogue group manager could cause some harm on their way out the door, for example.
I think a good solution for this would be needing +1s on the ticket from group members before it can be deleted, with a few possible exceptions of old groups with only 1 or 2 people in them.
IMHO, we should add the majority of git-* and svn-* groups to this list of not needing +1's AIUI, most of these groups were created for access control for source control on fedora hosted. And most probably not used at all anymore.
cheers, ryanlerch
We now have 5 requests to remove various no longer used groups.
I've enabled audit logging on our ipa01 instance, so we have audit logs (and I intend to back them up and keep them forever). So we can tell when a group was deleted by whom. We also have a db dump from fas2 before the switchover where we can look at who was in what group or what created it.
So, I would like to propose:
- we will remove groups on request/ticket from a group manager.
- we will not seek out groups to remove, as them being there doesn't
really hurt anything.
Thoughts?
Otherwise I think if we have the audit log then we should be free to delete the groups as needed. It will likely be a rare request in future, the new account system has triggered a spring clean I think.
Mark _______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapro... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
If groups are referenced by name only and data can be found later it should be ok. (Some systems have used group IDs that can be unique, but I am not aware of any at the moment, the same ID can be impossible to create. In that case group should just be hidden from general users.)
Jan
________________________________ From: Kevin Fenzi kevin@scrye.com Sent: Monday, April 19, 2021 9:29 PM To: infrastructure@lists.fedoraproject.org infrastructure@lists.fedoraproject.org Subject: account system group deletions
Greetings.
I thought I would bring up for dicussion here something thats come up after the new account system has been put in place.
Namely, how do we handle group deletions. In the FAS2 world, we never deleted anything. I think this was partly due to an over abundence of caution (there could be files owned by the group left over on various machines) and partly just because it was easier.
We now have 5 requests to remove various no longer used groups.
I've enabled audit logging on our ipa01 instance, so we have audit logs (and I intend to back them up and keep them forever). So we can tell when a group was deleted by whom. We also have a db dump from fas2 before the switchover where we can look at who was in what group or what created it.
So, I would like to propose:
* we will remove groups on request/ticket from a group manager. * we will not seek out groups to remove, as them being there doesn't really hurt anything.
Thoughts?
If there's no objections soon I will go ahead and process those requests.
kevin
On Mon, Apr 19, 2021 at 11:29:41AM -0700, Kevin Fenzi wrote:
Greetings.
I thought I would bring up for dicussion here something thats come up after the new account system has been put in place.
Namely, how do we handle group deletions. In the FAS2 world, we never deleted anything. I think this was partly due to an over abundence of caution (there could be files owned by the group left over on various machines) and partly just because it was easier.
We now have 5 requests to remove various no longer used groups.
I've enabled audit logging on our ipa01 instance, so we have audit logs (and I intend to back them up and keep them forever). So we can tell when a group was deleted by whom. We also have a db dump from fas2 before the switchover where we can look at who was in what group or what created it.
So, I would like to propose:
- we will remove groups on request/ticket from a group manager.
- we will not seek out groups to remove, as them being there doesn't
really hurt anything.
Thoughts?
+1 for me on groups.
This does raise the question about user accounts no? We could have a group that is created with the same name as a group that was deleted, and suddenly our auditing trail needs to take into account a time component as group X at time A may be different than group X at time B.
I've the feeling that user accounts are a tad more sensitive and thus we may want to keep our current policies, I'm raising the question here nonetheless :)
Pierre
On Mon, Apr 19, 2021 at 08:44:43PM +0200, Pierre-Yves Chibon wrote:
+1 for me on groups.
This does raise the question about user accounts no? We could have a group that is created with the same name as a group that was deleted, and suddenly our auditing trail needs to take into account a time component as group X at time A may be different than group X at time B.
Yeah. Luckily we don't add many groups anymore...so I don't think that will be too much of a problem.
I've the feeling that user accounts are a tad more sensitive and thus we may want to keep our current policies, I'm raising the question here nonetheless :)
Yeah, user accounts are a different thing. The case you mention above with groups could be a lot more confusing with users... user foo at time A is not the same as foo at time B. I'm ok with just keeping out policy of not deleting accounts except under exceptional cases.
kevin
On ma, 19 huhti 2021, Kevin Fenzi wrote:
On Mon, Apr 19, 2021 at 08:44:43PM +0200, Pierre-Yves Chibon wrote:
+1 for me on groups.
This does raise the question about user accounts no? We could have a group that is created with the same name as a group that was deleted, and suddenly our auditing trail needs to take into account a time component as group X at time A may be different than group X at time B.
Yeah. Luckily we don't add many groups anymore...so I don't think that will be too much of a problem.
I've the feeling that user accounts are a tad more sensitive and thus we may want to keep our current policies, I'm raising the question here nonetheless :)
Yeah, user accounts are a different thing. The case you mention above with groups could be a lot more confusing with users... user foo at time A is not the same as foo at time B. I'm ok with just keeping out policy of not deleting accounts except under exceptional cases.
FreeIPA has a concept of life-cycle management for users -- see 'ipa help stageuser' and 'ipa help user-stage'.
More about it: Design page: https://www.freeipa.org/page/V4/User_Life-Cycle_Management User documentation: Command line: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm... Web UI: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm...
On Tue, Apr 20, 2021 at 08:53:59AM +0300, Alexander Bokovoy wrote:
On ma, 19 huhti 2021, Kevin Fenzi wrote:
On Mon, Apr 19, 2021 at 08:44:43PM +0200, Pierre-Yves Chibon wrote:
+1 for me on groups.
This does raise the question about user accounts no? We could have a group that is created with the same name as a group that was deleted, and suddenly our auditing trail needs to take into account a time component as group X at time A may be different than group X at time B.
Yeah. Luckily we don't add many groups anymore...so I don't think that will be too much of a problem.
I've the feeling that user accounts are a tad more sensitive and thus we may want to keep our current policies, I'm raising the question here nonetheless :)
Yeah, user accounts are a different thing. The case you mention above with groups could be a lot more confusing with users... user foo at time A is not the same as foo at time B. I'm ok with just keeping out policy of not deleting accounts except under exceptional cases.
FreeIPA has a concept of life-cycle management for users -- see 'ipa help stageuser' and 'ipa help user-stage'.
More about it: Design page: https://www.freeipa.org/page/V4/User_Life-Cycle_Management User documentation: Command line: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm... Web UI: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm...
Interesting. Will read through those.
kevin
On Mon, Apr 19, 2021 at 12:33:02PM -0700, Kevin Fenzi wrote:
Yeah. Luckily we don't add many groups anymore...so I don't think that will be too much of a problem.
When we get the group-SSO thing figured out with Discourse, there will suddenly be a concrete and easy thing that can be done with group membership that previously a lot of teams didn't take advantage of. So we might have more in the future.
infrastructure@lists.fedoraproject.org
-
Alexander Bokovoy -
Ben Cotton -
Jan K -
Kevin Fenzi -
Mark O'Brien -
Matthew Miller -
Pierre-Yves Chibon -
Ryan Lerch