You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues-all@impala.apache.org by "Amogh Margoor (Jira)" <ji...@apache.org> on 2021/11/24 12:18:00 UTC

[jira] [Resolved] (IMPALA-11027) Support for ShellBasedUnixGroupMapping for Impala's user delegation via groups

     [ 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)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org