Return-Path: X-Original-To: apmail-hadoop-hdfs-user-archive@minotaur.apache.org Delivered-To: apmail-hadoop-hdfs-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id EE96617FE0 for ; Wed, 3 Jun 2015 13:59:48 +0000 (UTC) Received: (qmail 98290 invoked by uid 500); 3 Jun 2015 13:59:41 -0000 Delivered-To: apmail-hadoop-hdfs-user-archive@hadoop.apache.org Received: (qmail 98175 invoked by uid 500); 3 Jun 2015 13:59:41 -0000 Mailing-List: contact user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hadoop.apache.org Delivered-To: mailing list user@hadoop.apache.org Received: (qmail 98161 invoked by uid 99); 3 Jun 2015 13:59:41 -0000 Received: from Unknown (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Jun 2015 13:59:41 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id C5BF4CB12D for ; Wed, 3 Jun 2015 13:59:40 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.001 X-Spam-Level: *** X-Spam-Status: No, score=3.001 tagged_above=-999 required=6.31 tests=[FSL_HELO_BARE_IP_2=0.001, HTML_MESSAGE=3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id oR9RnIhviPnf for ; Wed, 3 Jun 2015 13:59:29 +0000 (UTC) Received: from relayvx12c.securemail.intermedia.net (relayvx12c.securemail.intermedia.net [64.78.52.187]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id C13C72143B for ; Wed, 3 Jun 2015 13:59:28 +0000 (UTC) Received: from securemail.intermedia.net (localhost [127.0.0.1]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id 1388877C42 for ; Wed, 3 Jun 2015 06:59:27 -0700 (PDT) Subject: Re: HTTPFS without impersonation MIME-Version: 1.0 x-echoworx-emg-received: Wed, 3 Jun 2015 06:59:27.045 -0700 x-echoworx-msg-id: 4fc8dc7c-6ce5-4d75-8690-6d3264d03430 x-echoworx-action: delivered Received: from 10.254.155.17 ([10.254.155.17]) by emg-ca-1-2 (JAMES SMTP Server 2.3.2) with SMTP ID 741 for ; Wed, 3 Jun 2015 06:59:27 -0700 (PDT) Received: from MBX080-W4-CO-2.exch080.serverpod.net (unknown [10.224.117.102]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id B960D77C42 for ; Wed, 3 Jun 2015 06:59:26 -0700 (PDT) Received: from MBX080-W4-CO-2.exch080.serverpod.net (10.224.117.102) by MBX080-W4-CO-2.exch080.serverpod.net (10.224.117.102) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 3 Jun 2015 06:59:25 -0700 Received: from MBX080-W4-CO-2.exch080.serverpod.net ([10.224.117.102]) by mbx080-w4-co-2.exch080.serverpod.net ([10.224.117.102]) with mapi id 15.00.1044.021; Wed, 3 Jun 2015 06:59:25 -0700 From: Larry McCay To: "user@hadoop.apache.org" Thread-Topic: HTTPFS without impersonation Thread-Index: AdCd4A9JjcL8buQ2RQaDpAlhIAbI1wATMKOAAAAjBAAAAG3TgAAANcsAAADhdIAAAVR+AAAB2dsA Date: Wed, 3 Jun 2015 13:59:25 +0000 Message-ID: References: <4763CFFD-015D-4BBF-AD48-A8E6D71794BF@hortonworks.com> <0535675D-F71F-45BD-BB56-6EC64223E5BF@hortonworks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [108.24.150.25] x-source-routing-agent: Processed Content-Type: multipart/alternative; boundary="_000_C5276CDAD5DF4E00B2466FD4AED0B861hortonworkscom_" --_000_C5276CDAD5DF4E00B2466FD4AED0B861hortonworkscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sorry. No, I don=92t think that this is possible and I don=92t think that you shou= ld try and manipulate the proxy settings in such a way that team users are = configured as trusted proxies. That would introduce risk of exactly the sort of things that you are trying= to avoid. On Jun 3, 2015, at 9:06 AM, Nathaniel Braun > wrote: Hi, Thanks for your answer. I=92m not sure I understand it all, though. Of course, you could send a request to another team=92s HTTPFS instance. Bu= t you won=92t be necessarily be granted access to every operations (based o= n Kerberos authentication, for instance). Anyway, my objective was to use HTTPFS without the impersonation mechanisms= . Thus, a given HTTPFS instance would be only granted the right of the user= s under which it runs. Do you think this is possible? Thanks & regards, Nathaniel From: Larry McCay [mailto:lmccay@hortonworks.com] Sent: mercredi 3 juin 2015 14:28 To: user@hadoop.apache.org Subject: Re: HTTPFS without impersonation inline... On Jun 3, 2015, at 8:03 AM, Nathaniel Braun > wrote: Hi, We want to let users & teams be able to run their HTTPFS in order to isolat= e instances. One team thus cannot crash another team=92s HTTPFS instance. For my own clarity... How does this keep them from using instances that are running as another te= am user? If the instances are running locally to the user or on a team user specific= gateway machine then it should be able to run as http and have the same be= nefit of physical isolation - no? If they are running on edge nodes of the cluster then can=92t a user send a= request to any HttpFs instance? Now, I make the following request: curl "localhost:14000/webhdfs/v1/user/team_user?op=3DLISTSTATUS&user.name= =3Dteam_user" And I get the following response: {"RemoteException":{"message":"User: team_user is not allowed to impersonat= eteam_user","exception":"RemoteException","javaClassName":"org.apache.hadoo= p.ipc.RemoteException"}} We provide the concept of trusted proxies in Hadoop. The number of these trusted entities should ideally be kept to a minimum. A proliferation of such trust relationships can lead to unexpected results = and a management headache. I wouldn=92t want to see teamUser1 be trusted to impersonate teamUser2 or H= DFS for instance - avoid using =91*=92 for the groups property. When using a gateway like HttpFs or Knox you want that server to be trusted= to act on behalf of other users not every user that uses it to be trusted. My suggestion is to use HttpFs as a proxy server running as a single user t= hat can be configured as trusted. Physical isolation can be used across tenants so that they don=92t have acc= ess to the others instances. Thanks, Nathaniel From: Larry McCay [mailto:lmccay@hortonworks.com] Sent: mercredi 3 juin 2015 13:57 To: user@hadoop.apache.org Subject: Re: HTTPFS without impersonation Out of curiosity, what is the added benefit of having HttpFs run as separat= e team users give you? If the APIs are invoked with SPNEGO or a user.name of the appropriate user = don=92t you get the same permissions based protections? Generally speaking, gateways such as HttpFs provide access on behalf of end= users. On Jun 3, 2015, at 7:44 AM, Nathaniel Braun > wrote: Hi, Thanks for your answer. With this setup, only the HTTP user will be able to impersonate other users= , so HTTPFS has to run with the HTTP user. Instead, I need users to run HTTPFS with their own user, not with the HTTP = user. Thanks From: Wellington Chevreuil [mailto:wellington.chevreuil@gmail.com] Sent: mercredi 3 juin 2015 13:41 To: user@hadoop.apache.org Subject: Re: HTTPFS without impersonation Hi, do u have below property on core-site.xml file used by your hdfs? hadoop.proxyuser.HTTP.hosts * hadoop.proxyuser.HTTP.groups * Hello all, We need to run several HTTPFS instances on our Hadoop cluster, with differe= nt users (basically, one HTTPFS per team). In our setup, each HTTPFS instance runs as a team user and is allowed write= access to that user=92s directory only (so, HTTPFS does not run as the htt= pfs user). However, this setup does not work, as we get exceptions related to imperson= ation, such as this one: {"RemoteException":{"message":"User: team_user is not allowed to impersonat= eteam_user","exception":"RemoteException","javaClassName":"org.apache.hadoo= p.ipc.RemoteException"}} So, it seems that HTTPFS unconditionally tries to impersonate a user, even = though it=92s running as that same user. Is there a way to somehow disable = impersonation? Thanks for your help. Regards, Nathaniel --_000_C5276CDAD5DF4E00B2466FD4AED0B861hortonworkscom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Sorry.
No, I don=92t think that this is possible and I don=92t think that you= should try and manipulate the proxy settings in such a way that team users= are configured as trusted proxies.
That would introduce risk of exactly the sort of things that you are t= rying to avoid.

On Jun 3, 2015, at 9:06 AM, Nathaniel Braun <n.braun@criteo.com> wrote:

Hi,
 
Thanks for your answer. I=92m not sure I understand it all= , though.
 
Of course, you could send a request to another team=92s HT= TPFS instance. But you won=92t be necessarily be granted access to every op= erations (based on Kerberos authentication, for instance).
 
Anyway, my objective was to use HTTPFS without the imperso= nation mechanisms. Thus, a given HTTPFS instance would be only granted the = right of the users under which it runs. Do you think this is possible?
 
Thanks & regards,
Nathaniel
 
 
 
From:=  Larry McCay [mailto:lmccay@hortonworks.com] 
Sent: mercredi 3 j= uin 2015 14:28
To: user@hadoop.apache.org
Subject: Re: HTTPF= S without impersonation
 
inline...
 
On Jun 3, 2015, at 8:03 AM, Nathaniel Braun <n.braun@cri= teo.com> wrote:


Hi,
 
We want to let users & teams be able to run their HTTP= FS in order to isolate instances. One team thus cannot crash another team= =92s HTTPFS instance.
 
 
For my own clarity...
How does this keep them from using instances that are running as another te= am user?
If the instances are running locally to the user or on a team user specific= gateway machine then it should be able to run as http and have the same be= nefit of physical isolation - no?
If they are running on edge nodes of the cluster then can=92t a user send a= request to any HttpFs instance?


Now, I make the following request:
 
curl "localhost:14000/webhdfs/v1/user/team_user?op=3DLIST= STATUS&user.name=3Dteam_user"
 
And I get the following response:
 
{"RemoteException":{"message":"User: team_user is not allowed to impersonateteam_use= r","exception":"RemoteException","javaCla= ssName":"org.apache.hadoop.ipc.RemoteException"}}
 
 
We provide the concept of trusted proxies in Hadoop.
The number of these trusted entities should ideally be kept to a minimum.
A proliferation of such trust relationships can lead to unexpected results = and a management headache.
 
I wouldn=92t want to see teamUser1 be trusted to impersonate teamUser2 or H= DFS for instance - avoid using =91*=92 for the groups property.<= /div>
 
When using a gateway like HttpFs or Knox you want that server to be trusted= to act on behalf of other users not every user that uses it to be trusted.=
 
My suggestion is to use HttpFs as a proxy server running as a single user t= hat can be configured as trusted.
Physical isolation can be used across tenants so that they don=92t have acc= ess to the others instances.


Thanks,
Nathaniel
 
From:=  Larry McCay [mailto:lmccay@hortonworks.com] 
Sent: mercredi 3 j= uin 2015 13:57
To: user@hadoop.apache.org
Subject: Re: HTTPF= S without impersonation
 
Out of curiosity, what is the added benefit of having HttpFs run as separat= e team users give you?
If the APIs are invoked with SPNEGO or a user.name of the appropriate user = don=92t you get the same permissions based protections?
 
Generally speaking, gateways such as HttpFs provide access on behalf of end= users.
 
On Jun 3, 2015, at 7:44 AM, Nathaniel Braun <n.braun@criteo.com> wrote:



Hi,
 
Thanks for your answer.
 
With this setup, only the HTTP user will be able to impersonate other users, so HTTPFS has to run with the <= /span>HTTP user.
 
Instead, I need users to run HTTPFS with their own user, n= ot with the HTTP user.
 
Thanks
 
From:=  Wellington Chevreuil [mailto:wellington.ch= evreuil@gmail.com]  Sent: mercredi 3 j= uin 2015 13:41
To: user@hadoop.apache.org
Subject: Re: HTTPF= S without impersonation
 

Hi, do u have below property on core-site.xml file used by your hdfs?<= /o:p>

<property>
    <name>hadoop.proxyuser.HTTP.hosts</name>
    <value>*</value>
  </property>
  <property>
    <name>hadoop.proxyuser.HTTP.groups</name>     <value>*</value>
  </property>

Hello all,
 
We need to run several HTTPFS instances on our Hadoop cluster, with differe= nt users (basically, one HTTPFS per team).
 
In our setup, each HTTPFS instance runs as a team user and is allowed write= access to that user=92s directory only (so, HTTPFS does not run as the htt= pfs user).
 
However, this setup does not work, as we get exceptions related to imperson= ation, such as this one:
 
{"RemoteException":{"= message":"User: team_user is not = allowed to impersonateteam_user","exception":"Re= moteException","javaClassName":"org.apache.hadoop.ipc.R= emoteException"}}
 
So, it seems that HTTPFS unconditionally tries to impersonate a user, ev= en though it=92s running as that same user. Is there a way to somehow d= isable impersonation?
 
Thanks for your help.
 
Regards,
Nathaniel

--_000_C5276CDAD5DF4E00B2466FD4AED0B861hortonworkscom_--