On 7/13/2022 10:07 AM, Dave Botsch ([email protected]) wrote:
I suspect our user deprovisioning scripts would break by trying to explicitly remove users from those groups. Though would be easy enough to fix. And I'm in favor of having this extra output.
Several replies mentioned that the user deprovisioning scripts use the output of "pts membership <user>"to drive something like:
for each <group> in "pts membership <user>" pts removeuser <user> <group>where an error from "pts removeuser" causes the deprovisioning operation to fail.
I am curious, is the removal of the user from all groups performed as a step to be followed by
pts delete <user> or is the <user> entity left intact to preserve the name-to-id mapping?If the "pts removeuser" calls are followed by "pts delete", then the "pts removeuser" calls are unnecessary overhead since "pts delete <user>" will automatically remove the user from all groups as part of the deletion process. The removal will take a single RPC and reduce the number of UBIK write transactions necessary to perform the operation.
On the other hand, if the intent is to preserve the name-to-id mapping, in OpenAFS the <user> will still be a member of "system:anyuser" and "system:authuser". AuriStorFS supports the ability to disable a pts user entity so that the name-to-id mapping can be preserved while at the same time altering the current protection set for the user such that it is equivalent to the "anonymous" user. However, OpenAFS does not have this functionality.
In OpenAFS, an attempt to "pts remove user system:anyuser" or "pts remove user system:authuser" will fail with a PRNOENT error "User or group doesn't exist" indicating that the user is not a member of the group. The error is ambiguous because there is no context to inform the caller whether the problem is (1) the "group" from which the "user" is to be removed from does not exist; or (2) the user is not a member of the group which is the intended outcome.
I will argue that in this case, the protection service should return success if the attempt to remove a user from a group fails because the user is not a member. Such a change would also remove the ambiguity surrounding the PRNOENT error ensuring that it means that the group does not exist.
If such a change was applied to PR_RemoveFromGroup() then "pts removeuser <user> system:anyuser" and "pts removeuser <user> system:authuser" would succeed instead of fail. An unnecessary RPC would be issued but there would be no script failure.
That is a question for the OpenAFS release team. I am considering this change for the next AuriStorFS v2022.xx release.Two questions/thoughts would be: 1) If this is a "backwards-incompatible" change (is it?) should it be reserved for the next major version upgrade (2.0) ?
2) Use of a flag to pts membership to include (or not include) explicit and implicit membership, as I might very well want to filter the output... the question then becomes which way should be the "default"?
There is no well-defined meaning for implicit vs explicit group membership at the protocol layer. The Protection Service return from the PR_ListElements RPC is an array of integers (pts ids). The concept of implicit vs explicit group membership management is a server side implementation detail.
I suspect there are few on this mailing list that remember that when the concept of foreign users was added to the Protection Service there was a compile time option to determine if the membership of "system:authuser@foreign" groups were explicit or implicit. The implicit membership option was removed from the code base many years ago. However, in many regards the implicit membership model makes a lot more sense than the explicit model. The explicit model can result in a foreign user unintentionally missing from system:authuser@foreign. This failure is very difficult to debug.
Another reason for converting "system:authuser@foreign" to an implicit membership group is to ensure that the management of local and foreign users is consistent, and to ensure that the generated Current Protection Set for a local and foreign user is consistent.
Gary Buhrmaster requested the ability to label group memberships as being explicit or implicit. In my opinion, exposing the explicit vs implicit implementation detail to the pts client would be an abstraction layer violation. For the same reason I would be reluctant to add a "pts membership <user> -explicit" switch.
Switches such as -no-system-anyuser and -no-system-authuser could be added and when set the "pts" command could filter out the existence of groups -101 and -102. Although I find such options ugly compared to ensuring that there is no failure when attempting to remove an explicit user-group membership that is not present.
thanks.
Thank you all for the feedback. Jeffrey Altman P.S. - I really dislike top posting on mailing lists.
On Wed, Jul 13, 2022 at 09:49:29AM -0400, Jeffrey E Altman wrote:The Protection Service groups fall into two categories. Those with explicit membership lists and those with implicit membership lists. For example, the "system:anyuser" and "system:authuser" groups are implicit whereas "system:administrators", "system:ptsviewers", and "system:authuser@foreign-realm" groups are explicit. The output of "pts membership" only includes memberships in explicit membership groups. This has a negative impact inexperienced end users that might be unaware that they are members of the "system:anyuser" and "system:authuser" groups. This behavior also leads to an inconsistency between the behavior for foreign and local users because foreign users are not members of "system:authuser" and are members of "system:authuser@foreign" which is included in the membership list because that group has an explicit membership list. The AuriStorFS Protection service also makes a distinction between "user" and "machine" or "network" entities where "machine" and "network" entities are not members of the "system:authuser" or "system:authuser@foreign" groups. This distinction is not apparent from the output of "pts membership" because of the exclusion of implicit groups. AuriStor is considering a change to "pts membership" output to include implicit memberships in the output of "pts membership". With this change the output of these commands $ pts membership anonymous Groups anonymous (id: 32766) is a member of: $ pts membership testuser Groups anonymous (id: 112) is a member of: $ pts membership testuser@foreign Groups anonymous (id: 43282) is a member of: system:authuser@foreign becomes $ pts membership anonymous Groups anonymous (id: 32766) is a member of: system:anyuser $ pts membership testuser Groups anonymous (id: 112) is a member of: system:anyuser system:authuser $ pts membership testuser@foreign Groups anonymous (id: 43282) is a member of: system:authuser@foreign system:anyuser The question for cell admins is whether anyone is aware of any internal scripts which process the output of "pts membership" which will break as a result of the inclusion of the implicit groups "system:anyuser" and "system:authuser" in output. Your assistance is appreciated. Jeffrey Altman AuriStor, Inc.
smime.p7s
Description: S/MIME Cryptographic Signature
