Hi Colin. I've removed that requirement from the KIP and updated the PR accordingly.
Ron On Fri, Aug 28, 2020 at 2:27 PM Colin McCabe <cmcc...@apache.org> wrote: > Hi Ron, > > Thanks for the update. I agree with all of these changes, except I think > we should discuss this one further: > > On Wed, Aug 26, 2020, at 14:59, Ron Dagostino wrote: > > > > 2. We added a restriction to not allow users who authenticated using > > delegation tokens to create or update user SCRAM credentials. We don't > > allow such authenticated users to create new tokens, and it would be odd > if > > they could create a new user or change the password of the user for the > > token. > > > > I don't think these two restrictions are comparable. It seems to me that > we forbid creating a new token based on an existing token in order to force > users of delegation tokens to re-authenticate periodically through the > regular auth system. If they could just create a new token based on their > old token, there would be an obvious "wishing for more wishes" problem and > they could just sidestep the regular authentication system entirely once > they had a token. > > This issue doesn't exist here, since creating a new SCRAM user doesn't do > anything to extend the life of the existing delegation token. If the user > has the permission to change SCRAM users, I don't see any reason why we > should forbid them from doing just that. Users of delegation tokens > shouldn't be second-class citizens. A user with ALTER on CLUSTER should > have all the permissions associated with ALTER on CLUSTER, regardless of if > they logged in with Kerberos, delegation tokens, SCRAM, etc. etc. I don't > think the proposed restriction you mention here is consistent with that. > > best, > Colin >
