Mailing-List: contact common-user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-user@hadoop.apache.org
Received-SPF: pass (athena.apache.org: domain of ted.dunning@gmail.com
 designates 209.85.217.218 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=d8QDvj8Mgq0WAo7HHtZOKtmGrkijUG2QU95XfA7Kquk3b04PX52Xj3PvHjatQu+Z2F
         oX3YqQ4UscRy7E0tvTWhSmkz2fYPQbkVMQ96ysbdY2xOunoJob6KkGg4hleTNiGu8Ew+
         cXjtB3khP7OI5bKE5cSqQPdniLTiDxOOsITFs=
MIME-Version: 1.0
In-Reply-To: <4A68E40E.2000701@holsman.net>
References: 
 <2AAFC2B9E4C5DC4F859F154FB664CF5F061A86C3@EVSBNG01.ad.office.aol.com>
	<1c5747850907222345vf912191s7b03b3f2d1a425fd@mail.gmail.com>
	<c7d45fc70907230020q42692e69l344d2e99eabbf71d@mail.gmail.com>
	<4A683A28.6030902@apache.org>
 <d6d7c4410907230917v5762ad7em12616d5f06af1757@mail.gmail.com>
	<c7d45fc70907231119j42a25641v1e01adbd16dc4c87@mail.gmail.com>
	<4A68E40E.2000701@holsman.net>
From: Ted Dunning <ted.dunning@gmail.com>
Date: Thu, 23 Jul 2009 17:52:12 -0700
Message-ID: <c7d45fc70907231752h5f4a5194yfc8542f4bb089416@mail.gmail.com>
Subject: Re: Remote access to cluster using user as hadoop
To: common-user@hadoop.apache.org
Content-Type: multipart/alternative; boundary=000e0cd3f932f261f7046f690497

--000e0cd3f932f261f7046f690497
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Interesting approach.

My guess is that this would indeed protect the datanodes from accidental
"attack" by stopping access before they are involved.

You might also consider just changing the name of the magic hadoop user to
something that is more unlikely.  The name "hadoop" is not far off what
somebody might come up with as a user name for experimenting or running
scheduled jobs.

On Thu, Jul 23, 2009 at 3:28 PM, Ian Holsman <lists@holsman.net> wrote:

> I was thinking of alternatives similar to creating a proxy nameserver that
> non-privileged users can attach to that forwards those to the "real"
> nameserver or just hacking the nameserver so that it switches "hadoop" to
> "hadoop_remote" for sessions from untrusted IP's.
>
> not being familiar with the code, I am presuming that there is a point
> where the code determines the userID. can anyone point me to that bit?
> I just want to hack it to  downgrade superusers, and it doesn't have to be
> too clean or work for every edge case. it's more to stop accidental
> problems.
>


-- 
Ted Dunning, CTO
DeepDyve

--000e0cd3f932f261f7046f690497--