You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-issues@hadoop.apache.org by "Arpit Agarwal (JIRA)" <ji...@apache.org> on 2014/06/25 20:58:25 UTC

[jira] [Comment Edited] (HADOOP-10565) Support IP ranges (CIDR) in proxyuser.hosts

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

Arpit Agarwal edited comment on HADOOP-10565 at 6/25/14 6:57 PM:
-----------------------------------------------------------------

Hi [~benoyantony],

Thanks a lot for researching the DNS settings, this is good to know! I agree with removing the cache from MachineList. The default Java behavior for caching DNS entries looks sensible and most administrators should not need to tweak it.

You are right that the existing code also performs DNS lookups in a loop so we don't have to fix it right now.

Other points:
# {{IllegalArgumentException}} in MachineList constructor should be propagated to the caller. We don't want to start the service if the configuration is bad.
# There are still coding style issues in MachineList.java. e.g. missing spaces around {{=}}, missing spaces around {{>}} operators, extra spaces before {{;}}, missing space after closing {{\}}}.

+1 if these are fixed and the cache is removed.


was (Author: arpitagarwal):
Hi [~benoyantony],

Thanks a lot for researching the DNS settings, this is good to know! I agree with removing the cache from MachineList. The default Java behavior for caching DNS entries looks sensible and most administrators should not need to tweak it. From http://docs.oracle.com/javase/7/docs/technotes/guides/net/properties.html

{quote}
*networkaddress.cache.ttl*
    Specified in java.security to indicate the caching policy for successful name lookups from the name service.. The value is specified as integer to indicate the number of seconds to cache the successful lookup.

    A value of -1 indicates "cache forever". The default behavior is to cache forever when a security manager is installed, and to cache for an implementation specific period of time, when a security manager is not installed.

*networkaddress.cache.negative.ttl (default: 10)*
    Specified in java.security to indicate the caching policy for un-successful name lookups from the name service.. The value is specified as integer to indicate the number of seconds to cache the failure for un-successful lookups.

    A value of 0 indicates "never cache". A value of -1 indicates "cache forever".
{quote}

You are right that the existing code also performs DNS lookups in a loop so we don't have to fix it right now.

Other points:
# {{IllegalArgumentException}} in MachineList constructor should be propagated to the caller. We don't want to start the service if the configuration is bad.
# There are still coding style issues in MachineList.java. e.g. missing spaces around {{=}}, missing spaces around {{>}} operators, extra spaces before {{;}}, missing space after closing {{\}}}.

+1 if these are fixed and the cache is removed.

> Support IP ranges (CIDR) in  proxyuser.hosts
> --------------------------------------------
>
>                 Key: HADOOP-10565
>                 URL: https://issues.apache.org/jira/browse/HADOOP-10565
>             Project: Hadoop Common
>          Issue Type: Sub-task
>          Components: security
>            Reporter: Benoy Antony
>            Assignee: Benoy Antony
>         Attachments: HADOOP-10565.patch, HADOOP-10565.patch, HADOOP-10565.patch
>
>
> In some use cases, there will be many hosts from which the user can impersonate. 
> This requires specifying many ips  in the XML configuration. 
> It is cumbersome to specify and maintain long list of ips in proxyuser.hosts
> The problem can be solved if we enable proxyuser.hosts to accept ip ranges in CIDR format.
> In addition, the current ip authorization involve a liner scan of the ips and an attempt to do InetAddress.getByName()  for each ip/host. 
> It may be beneficial to group this functionality of ip authorization by looking up  "ip addresses/host names/ip-ranges" into a separate class. This could be reused in other usecases which require similar functionality



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