mneethiraj commented on code in PR #788:
URL: https://github.com/apache/ranger/pull/788#discussion_r2669652833
##########
security-admin/src/main/java/org/apache/ranger/service/RangerBaseModelService.java:
##########
@@ -358,16 +350,33 @@ protected T populateEntityBeanForUpdate(T entityObj, V
vObj) {
}
if (!populateExistingBaseFields) {
- Long currentUserId = ContextUtil.getCurrentUserId();
+ Long updatedByUserId = resolveUserId(vObj.getUpdatedBy());
ret.setUpdateTime(DateUtil.getUTCDate());
- if (Objects.nonNull(currentUserId)) {
- ret.setUpdatedByUserId(currentUserId);
+ if (Objects.nonNull(updatedByUserId)) {
+ ret.setUpdatedByUserId(updatedByUserId);
}
}
return ret;
}
+ private Long resolveUserId(String userLoginId) {
+ Long userId = null;
+ if (Objects.equals(userLoginId, ContextUtil.getCurrentUserLoginId())) {
Review Comment:
`userLoginId` paramter name is misleading. The value sent is the name
provided in the view object - which can be specified by callers of REST API to
create/update policy/role/sevice/service-def, etc. This name should not be
trusted.
The challenge with grant/revoke scenario is that the authenticated user
(`ContextUtil.getCurrentUserId()`) can be the service-account, while the policy
changes should be recorded as the grantor user - the payload value in
`GrantRevokeRequest.grantor`. One approach to consider is to update
grant/revoke calls to reset `RangerSecurityContext` with the identity of the
grantor.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
