[ 
https://issues.apache.org/jira/browse/IMPALA-11027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amogh Margoor resolved IMPALA-11027.
------------------------------------
    Resolution: Fixed

> Support for ShellBasedUnixGroupMapping for Impala's user delegation via groups
> ------------------------------------------------------------------------------
>
>                 Key: IMPALA-11027
>                 URL: https://issues.apache.org/jira/browse/IMPALA-11027
>             Project: IMPALA
>          Issue Type: Improvement
>            Reporter: Amogh Margoor
>            Assignee: Amogh Margoor
>            Priority: Major
>
> When impala.doAs.user is set for user delegation, Impala checks if the 
> delegation is allowed or not based on either of the following:
>  # user mapping: Specified using 
> {code:java}
> authorized_proxy_user_config{code}
>  # groups mapping:  Specified using. authorized_proxy_group_config
>  
>  
> For checking group mapping currently JNIBasedUnixGroupMapping is supported 
> and not ShellBasedUnixGroupMapping. Ref: 
> [https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/GroupsMapping.html]
> This was done because of caveats that ShellBasedUnixGroupMapping spawns a new 
> shell command to figure out groups for 'impala.doAs.user' when group mapping 
> is specified. Many numerous shell commands could potentially cause issues 
> like resource crunch, file descriptor issues and also zombie processes. Hence 
> it is discouraged. However, we should support it for users that understand 
> these caveats well and still want to use it. One reason could be that other 
> components of impala might not have moved to JNI based group mapping and 
> still be using Shell based.
> Regarding caveats few things help:
>  # Chances are zombie process are very low.
>  # Due to vfork being used we do not see too much of resource consumption 
> during process spawning. On memory it takes around 8KB and duration of 
> process is around 16-17ms.
>  # immediate exec after vfork would ensure other resources that might get 
> cloned via vfork are present for very short duration.
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Reply via email to