account system group deletions

[Kevin Fenzi]

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

[Ben Cotton]

Post by Kevin Fenzi
* 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.

Post by Kevin Fenzi
* we will not seek out groups to remove, as them being there doesn't
really hurt anything.

That makes sense.


--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
infrastructure mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-***@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/***@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedo

[Kevin Fenzi]

Post by Ben Cotton

Post by Kevin Fenzi
* 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

[Mark O'Brien]

Post by Ben Cotton
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.

Post by Ben Cotton
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.
* 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

[Ryan Lerch]

Post by Mark O'Brien

Post by Ben Cotton
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

Post by Mark O'Brien

Post by Ben Cotton
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.
* 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
_______________________________________________
To unsubscribe send an email to
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
https://pagure.io/fedora-infrastructure

[Jan K]

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 <***@scrye.com>
Sent: Monday, April 19, 2021 9:29 PM
To: ***@lists.fedoraproject.org <***@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

[Pierre-Yves Chibon]

Post by Kevin Fenzi
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.
* 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
_______________________________________________
infrastructure mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-***@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/***@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastruc

[Kevin Fenzi]

Post by Pierre-Yves Chibon
+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.

Post by Pierre-Yves Chibon
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

[Alexander Bokovoy]

Post by Kevin Fenzi

Post by Pierre-Yves Chibon
+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.

Post by Pierre-Yves Chibon
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/html/configuring_and_managing_identity_management/managing-user-accounts-using-the-command-line_configuring-and-managing-idm
Web UI: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_identity_management/managing-user-accounts-using-the-idm-web-ui_configuring-and-managing-idm


--
/ Alexander Bokovoy
_______________________________________________
infrastructure mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-***@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/***@lists.fedoraproject.org
Do not reply to spam on the list, r

[Kevin Fenzi]

Post by Alexander Bokovoy

Post by Kevin Fenzi

Post by Pierre-Yves Chibon
+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.

Post by Pierre-Yves Chibon
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'.
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/html/configuring_and_managing_identity_management/managing-user-accounts-using-the-command-line_configuring-and-managing-idm
Web UI: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_identity_management/managing-user-accounts-using-the-idm-web-ui_configuring-and-managing-idm

Interesting. Will read through those.

kevin

[Matthew Miller]

Post by Kevin Fenzi
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.

--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
infrastructure mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-***@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/***@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructu