Re: Question for admins regarding pts membership output

As of the writing of this reply there have been several other replies to 
my original e-mail from Ed Rude, Richard Brittain, and Gary Buhrmaster.  
As there is some overlap in the responses I will reply once to Dave 
Botsch's but I intend to touch on the feedback from all of the above.

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.


> 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) ?
That is a question for the OpenAFS release team.   I am considering this 
change for the next AuriStorFS v2022.xx release.
> 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.
>>
>
>