Re: [OpenAFS] Question for admins regarding pts membership output
On 7/15/2022 6:18 PM, Richard Brittain (richard.britt...@dartmouth.edu)
wrote:
On 2022-07-15, 09:04, "Jeffrey E Altman" wrote:
On 7/13/2022 6:07 PM, Richard Brittain (richard.britt...@dartmouth.edu)
wrote:
> I hope that doesn't lead people to expect 'pts membership
system:authuser' to show all users.
>
> Richard
I'm curious. Why would it be wrong for users to expect 'pts membership
system:authuser' and 'pts membership system:anyuser' to list their
membership assuming the caller had the necessary access rights?
Only that the output of system:authuser would be confusingly long, and what
would system:anyuser generate anyway ?. We also have scripts for 'show me
everyone who has access to this entity', which gets complicated with nested
groups, and I couldn't figure out what to display for 'everyone'. It would be
valid to ignore named users in the ACL and just say 'everyone' in that case.
What to display for "everyone" is easy, its "system:anyuser".
The output of system:authuser in OpenAFS would be close to the output of
pts listentries -user | grep -v '@' | grep -v 'anonymous' | gawk
'{print $1}'
In other words, the list of all user entries that are not foreign and
are not "anonymous". it would also exclude any IP address entries.
The output of system:anyuser would be
pts listentries -user | gawk '{print $1}'
again with the exception of all IP address entries. The difference is
that system:anyuser output includes "anonymous" and the foreign entities.
In an AuriStorFS world the system:authuser and system:anyuser lists
would also exclude "machine" and "network" entities.
Enumerating the membership of system:anyuser and system:authuser would
by default be restricted to "-showmembers self" which means that only
members of the system:administrators group would be able to enumerate
the membership.
A cell that wished to offer broader access might set "-showmembers
members" on system:authuser but that would be the same as "-showmembers
anyone" for "system:anyuser". I think the default is appropriate for
all cells.
Tangentially related, we use a wrapper to list AFS groups, which looks up a few
bits of useful information about each member besides their AFS username. This
is very user-friendly, but means lots of LDAP lookups and would take forever on
the full output of system:authuser.
Makes sense. That would take a while for a cell with several hundred
thousand users.
I can imagine a plugin for both the protection service and the pts
client that would allow the protection service to query LDAP or some
other service and return an opaque blob to the pts client to be unpacked
and displayed by the pts plugin.
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [OpenAFS] Question for admins regarding pts membership output
Only that the output of system:authuser would be confusingly long, and what would system:anyuser generate anyway ?. We also have scripts for 'show me everyone who has access to this entity', which gets complicated with nested groups, and I couldn't figure out what to display for 'everyone'. It would be valid to ignore named users in the ACL and just say 'everyone' in that case. Tangentially related, we use a wrapper to list AFS groups, which looks up a few bits of useful information about each member besides their AFS username. This is very user-friendly, but means lots of LDAP lookups and would take forever on the full output of system:authuser. I didn't know about pts delete automatically removing from groups - that does remove my only real use case for relying on the output of pts membership in decommissioning. Richard On 2022-07-15, 09:04, "Jeffrey E Altman" wrote: On 7/13/2022 6:07 PM, Richard Brittain (richard.britt...@dartmouth.edu) wrote: > I hope that doesn't lead people to expect 'pts membership system:authuser' to show all users. > > Richard I'm curious. Why would it be wrong for users to expect 'pts membership system:authuser' and 'pts membership system:anyuser' to list their membership assuming the caller had the necessary access rights? My primary objection to the existing behavior is that these groups are special and end users / administrators must understand that they are special. If an authorized user can obtain the membership list from 'pts membership system:authuser@foreign' why shouldn't the same be true for 'system:authuser'? If the concern is the cost of generating the result set, its no more expensive then executing 'pts listentries'. In a private response to my original message someone wrote that their cell uses the output of 'pts membership' to generate the list of entities that have access to a file object given the assigned ACL. This is a perfectly reasonable action to expect to work. However, the generated list will be incomplete when 'pts membership system:anyuser' and 'pts membership system:authuser' succeed while at the same time generate empty output. Jeffrey Altman
Re: [OpenAFS] Question for admins regarding pts membership output
On 7/13/2022 6:07 PM, Richard Brittain (richard.britt...@dartmouth.edu) wrote: I hope that doesn't lead people to expect 'pts membership system:authuser' to show all users. Richard I'm curious. Why would it be wrong for users to expect 'pts membership system:authuser' and 'pts membership system:anyuser' to list their membership assuming the caller had the necessary access rights? My primary objection to the existing behavior is that these groups are special and end users / administrators must understand that they are special. If an authorized user can obtain the membership list from 'pts membership system:authuser@foreign' why shouldn't the same be true for 'system:authuser'? If the concern is the cost of generating the result set, its no more expensive then executing 'pts listentries'. In a private response to my original message someone wrote that their cell uses the output of 'pts membership' to generate the list of entities that have access to a file object given the assigned ACL. This is a perfectly reasonable action to expect to work. However, the generated list will be incomplete when 'pts membership system:anyuser' and 'pts membership system:authuser' succeed while at the same time generate empty output. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
