[OpenAFS] Question for admins regarding pts membership output
Jeffrey E Altman
jaltman@auristor.com
Wed, 13 Jul 2022 22:23:40 -0400
This is a cryptographically signed message in MIME format.
--------------ms080906080102080805050802
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
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 (botsch@cnf.cornell.edu) 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.
>>
>
>
--------------ms080906080102080805050802
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DGswggXSMIIEuqADAgECAhBAAW0B1qVVQ32wvx2EXYU6MA0GCSqGSIb3DQEBCwUAMDoxCzAJ
BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy
MB4XDTE5MDkwNTE0MzE0N1oXDTIyMTEwMTE0MzE0N1owcDEvMC0GCgmSJomT8ixkAQETH0Ew
MTQxMEMwMDAwMDE2RDAxRDZBNTQwMDAwMDQ0NDcxGTAXBgNVBAMTEEplZmZyZXkgRSBBbHRt
YW4xFTATBgNVBAoTDEF1cmlTdG9yIEluYzELMAkGA1UEBhMCVVMwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQCY1TC9QeWnUgEoJ81FcAVnhGn/AWuzvkYRUG5/ZyXDdaM212e8
ybCklgSmZweqNdrfaaHXk9vwjpvpD4YWgb07nJ1QBwlvRV/VPAaDdneIygJJWBCzaMVLttKO
0VimH/I/HUwFBQT2mrktucCEf2qogdi2P+p5nuhnhIUiyZ71Fo43gF6cuXIMV/1rBNIJDuwM
Q3H8zi6GL0p4mZFZDDKtbYq2l8+MNxFvMrYcLaJqejQNQRBuZVfv0Fq9pOGwNLAk19baIw3U
xdwx+bGpTtS63Py1/57MQ0W/ZXE/Ocnt1qoDLpJeZIuEBKgMcn5/iN9+Ro5zAuOBEKg34wBS
8QCTAgMBAAGjggKcMIICmDAOBgNVHQ8BAf8EBAMCBPAwgYQGCCsGAQUFBwEBBHgwdjAwBggr
BgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEIGCCsGAQUF
BzAChjZodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NlcnRzL3RydXN0aWRjYWEx
Mi5wN2MwHwYDVR0jBBgwFoAUpHPa72k1inXMoBl7CDL4a4nkQuwwCQYDVR0TBAIwADCCASsG
A1UdIASCASIwggEeMIIBGgYLYIZIAYb5LwAGAgEwggEJMEoGCCsGAQUFBwIBFj5odHRwczov
L3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRt
bDCBugYIKwYBBQUHAgIwga0MgapUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJlZW4g
aXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmlj
YXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRp
ZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8v
dmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC90cnVzdGlkY2FhMTIuY3JsMB8GA1UdEQQY
MBaBFGphbHRtYW5AYXVyaXN0b3IuY29tMB0GA1UdDgQWBBR7pHsvL4H5GdzNToI9e5BuzV19
bzAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAFlm
JYk4Ff1v/n0foZkv661W4LCRtroBaVykOXetrDDOQNK2N6JdTa146uIZVgBeU+S/0DLvJBKY
tkUHQ9ovjXJTsuCBmhIIw3YlHoFxbku0wHEpXMdFUHV3tUodFJJKF3MbC8j7dOMkag59/Mdz
Sjszdvit0av9nTxWs/tRKKtSQQlxtH34TouIke2UgP/Nn901QLOrJYJmtjzVz8DW3IYVxfci
SBHhbhJTdley5cuEzphELo5NR4gFjBNlxH7G57Hno9+EWILpx302FJMwTgodIBJbXLbPMHou
xQbOL2anOTUMKO8oH0QdQHCtC7hpgoQa7UJYJxDBI+PRaQ/HObkwggaRMIIEeaADAgECAhEA
+d5Wf8lNDHdw+WAbUtoVOzANBgkqhkiG9w0BAQsFADBKMQswCQYDVQQGEwJVUzESMBAGA1UE
ChMJSWRlblRydXN0MScwJQYDVQQDEx5JZGVuVHJ1c3QgQ29tbWVyY2lhbCBSb290IENBIDEw
HhcNMTUwMjE4MjIyNTE5WhcNMjMwMjE4MjIyNTE5WjA6MQswCQYDVQQGEwJVUzESMBAGA1UE
ChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElEIENBIEExMjCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBANGRTTzPCic0kq5L6ZrUJWt5LE/n6tbPXPhGt2Egv7plJMoEpvVJ
JDqGqDYymaAsd8Hn9ZMAuKUEFdlx5PgCkfu7jL5zgiMNnAFVD9PyrsuF+poqmlxhlQ06sFY2
hbhQkVVQ00KCNgUzKcBUIvjv04w+fhNPkwGW5M7Ae5K5OGFGwOoRck9GG6MUVKvTNkBw2/vN
MOd29VGVTtR0tjH5PS5yDXss48Yl1P4hDStO2L4wTsW2P37QGD27//XGN8K6amWB6F2XOgff
/PmlQjQOORT95PmLkwwvma5nj0AS0CVp8kv0K2RHV7GonllKpFDMT0CkxMQKwoj+tWEWJTiD
KSsCAwEAAaOCAoAwggJ8MIGJBggrBgEFBQcBAQR9MHswMAYIKwYBBQUHMAGGJGh0dHA6Ly9j
b21tZXJjaWFsLm9jc3AuaWRlbnRydXN0LmNvbTBHBggrBgEFBQcwAoY7aHR0cDovL3ZhbGlk
YXRpb24uaWRlbnRydXN0LmNvbS9yb290cy9jb21tZXJjaWFscm9vdGNhMS5wN2MwHwYDVR0j
BBgwFoAU7UQZwNPwBovupHu+QucmVMiONnYwDwYDVR0TAQH/BAUwAwEB/zCCASAGA1UdIASC
ARcwggETMIIBDwYEVR0gADCCAQUwggEBBggrBgEFBQcCAjCB9DBFFj5odHRwczovL3NlY3Vy
ZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDADAgEB
GoGqVGhpcyBUcnVzdElEIENlcnRpZmljYXRlIGhhcyBiZWVuIGlzc3VlZCBpbiBhY2NvcmRh
bmNlIHdpdGggSWRlblRydXN0J3MgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBQb2xpY3kgZm91bmQg
YXQgaHR0cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNvbS9jZXJ0aWZpY2F0ZXMvcG9saWN5L3Rz
L2luZGV4Lmh0bWwwSgYDVR0fBEMwQTA/oD2gO4Y5aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRy
dXN0LmNvbS9jcmwvY29tbWVyY2lhbHJvb3RjYTEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMC
BggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFKRz2u9pNYp1zKAZewgy+GuJ
5ELsMA0GCSqGSIb3DQEBCwUAA4ICAQAN4YKu0vv062MZfg+xMSNUXYKvHwvZIk+6H1pUmivy
DI4I6A3wWzxlr83ZJm0oGIF6PBsbgKJ/fhyyIzb+vAYFJmyI8I/0mGlc+nIQNuV2XY8cypPo
VJKgpnzp/7cECXkX8R4NyPtEn8KecbNdGBdEaG4a7AkZ3ujlJofZqYdHxN29tZPdDlZ8fR36
/mAFeCEq0wOtOOc0Eyhs29+9MIZYjyxaPoTS+l8xLcuYX3RWlirRyH6RPfeAi5kySOEhG1qu
NHe06QIwpigjyFT6v/vRqoIBr7WpDOSt1VzXPVbSj1PcWBgkwyGKHlQUOuSbHbHcjOD8w8wH
SDbL+L2he8hNN54doy1e1wJHKmnfb0uBAeISoxRbJnMMWvgAlH5FVrQWlgajeH/6NbYbBSRx
ALuEOqEQepmJM6qz4oD2sxdq4GMN5adAdYEswkY/o0bRKyFXTD3mdqeRXce0jYQbWm7oapqS
ZBccFvUgYOrB78tB6c1bxIgaQKRShtWR1zMM0JfqUfD9u8Fg7G5SVO0IG/GcxkSvZeRjhYcb
TfqF2eAgprpyzLWmdr0mou3bv1Sq4OuBhmTQCnqxAXr4yVTRYHkp5lCvRgeJAme1OTVpVPth
/O7HJ7VuEP9GOr6kCXCXmjB4P3UJ2oU0NqfoQdcSSSt9hliALnExTEjii20B2nSDojGCAxQw
ggMQAgEBME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMO
VHJ1c3RJRCBDQSBBMTICEEABbQHWpVVDfbC/HYRdhTowDQYJYIZIAWUDBAIBBQCgggGXMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIyMDcxNDAyMjM0MFow
LwYJKoZIhvcNAQkEMSIEIEe/DZe9+YQk4DieAn+MFRmRaZ9p2IP44sC8TfGr0uvJMF0GCSsG
AQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UE
AxMOVHJ1c3RJRCBDQSBBMTICEEABbQHWpVVDfbC/HYRdhTowXwYLKoZIhvcNAQkQAgsxUKBO
MDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQg
Q0EgQTEyAhBAAW0B1qVVQ32wvx2EXYU6MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEq
MAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwIC
AUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAHRIkeaA9LXQg
UDDngkm6fdjVVFej5TBPFcxJN3CVAnWrSvy2VYeLt0EP8V+0p9bkkG4IFLQxtMYJFnTIeBcN
aRtJ6ZSUyucWvmqoe2YPk87ivBvWlT9C2wWUsowJ1aMQTIXAU4ChYY4PuRI5y8P6qQlhvtKS
9vjUwQKoBjVIzC2HmfATIUIUowiDsl4NhWFSh3+oBxTuB1pCl9SBaiOwM+NXiWGw+NOTnAzL
J2U1TRR4Jyw4Nw1p/xnkBMO1ppQGK6/U8f44p4Uk7/UeBm8OgupOJnEIggs1aKJcSN0LscYC
9n+iV8XknsxBCIo16lqMv5XMLIYuJ3roOegjsbBCGgAAAAAAAA==
--------------ms080906080102080805050802--