[jira] [Comment Edited] (HADOOP-10522) JniBasedUnixGroupMapping mishandles errors

["Kihwal Lee (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HADOOP-10522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13976089#comment-13976089 ] 

Kihwal Lee edited comment on HADOOP-10522 at 4/21/14 10:10 PM:
---------------------------------------------------------------

Thanks for the feedback, [~cmccabe] 
bq. getgrgrid_r does not set errno (or at least is not documented to do so by POSIX).
The patch does not use errno. It explicitly use the return value. The code before my patch used errno.

bq. Try (*env)->Throw(env, newRuntimeException("getgrouplist: error looking up user. %d (%s)", ret, terror(ret))) here instead.
I don't think it is correct to throw a RuntimeException when a user is not found (ENOENT).

bq.  Just because we get EINTR 5 times doesn't mean we should fail. 
Probably. I will fix that.

bq. Also, why are we increasing the buffer size when we get EINTR?
We don't.

Another bug in my patch is to return EIO when user/group is not found.  I will fix it and enable retries for EINTR forever in a separate jira. I will file one and attach a patch.


was (Author: kihwal):
Thanks for the feedback, [~cmccabe] 
bq. getgrgrid_r does not set errno (or at least is not documented to do so by POSIX).
The patch does not use errno. It explicitly use the return value.

bq. Try (*env)->Throw(env, newRuntimeException("getgrouplist: error looking up user. %d (%s)", ret, terror(ret))) here instead.
I don't think it is correct to throw a RuntimeException when a user is not found (ENOENT).

bq.  Just because we get EINTR 5 times doesn't mean we should fail. 
Probably. I will fix that.

bq. Also, why are we increasing the buffer size when we get EINTR?
We don't.

Another bug in my patch is to return EIO when user/group is not found.  I will fix it and enable retries for EINTR forever in a separate jira. I will file one and attach a patch.

> JniBasedUnixGroupMapping mishandles errors
> ------------------------------------------
>
>                 Key: HADOOP-10522
>                 URL: https://issues.apache.org/jira/browse/HADOOP-10522
>             Project: Hadoop Common
>          Issue Type: Bug
>            Reporter: Kihwal Lee
>            Assignee: Kihwal Lee
>            Priority: Critical
>             Fix For: 3.0.0, 2.4.1
>
>         Attachments: hadoop-10522.patch
>
>
> The mishandling of errors in the jni user-to-groups mapping modules can cause segmentation faults in subsequent calls.  Here are the bugs:
> 1) If {{hadoop_user_info_fetch()}} returns an error code that is not ENOENT, the error may not be handled at all.  This bug was found by [~cnauroth].
> 2)  In {{hadoop_user_info_fetch()}} and {{hadoop_group_info_fetch()}}, the global {{errno}} is directly used. This is not thread-safe and could be the cause of some failures that disappeared after enabling the big lookup lock.
> 3) In the above methods, there is no limit on retries.



--
This message was sent by Atlassian JIRA
(v6.2#6252)