Return-Path: X-Original-To: apmail-hadoop-mapreduce-user-archive@minotaur.apache.org Delivered-To: apmail-hadoop-mapreduce-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 C8AB0D8FC for ; Wed, 12 Sep 2012 10:29:23 +0000 (UTC) Received: (qmail 22155 invoked by uid 500); 12 Sep 2012 10:29:18 -0000 Delivered-To: apmail-hadoop-mapreduce-user-archive@hadoop.apache.org Received: (qmail 21906 invoked by uid 500); 12 Sep 2012 10:29:15 -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 21884 invoked by uid 99); 12 Sep 2012 10:29:15 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Sep 2012 10:29:15 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FSL_RCVD_USER,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of dechouxb@gmail.com designates 209.85.216.48 as permitted sender) Received: from [209.85.216.48] (HELO mail-qa0-f48.google.com) (209.85.216.48) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Sep 2012 10:29:07 +0000 Received: by qady1 with SMTP id y1so1170090qad.14 for ; Wed, 12 Sep 2012 03:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pOgj3UAK0ezjd3SNULeRb+lmzVLNT8UDBkdqmt5D2Y0=; b=UAS3/AlRDgrU9SLZIwjp/UtWbaWB9Ea09UiIDdpaedsfKNk0KVVK1PCiRBAI7Z0MV5 Ob5g7RN/+3dZKOES+fb4q5I9wBY+uxf/BYThJWwdyVyaSe0IaUvikGm+Azxd0Qy8ZWhM li7BtgrGEXOYuFMwDgADcpzERW2wI1Wmfsuk0bctqjl7dc1R8a1koEzTRmvitfLxWdYn 3JekvzbCT7srVIvDi7y7tV9/NTfh1z9ykoYnOHFQxYEWLMJTjDu1H0b3MGlS1ZsUXGYt 4Fh+wqSVCTkFhjyvpRKq2Zvu9/38pIks/X4QKktsRI7VuftXXsOZS3xa1a2StwbQL0W8 ua7w== MIME-Version: 1.0 Received: by 10.229.122.220 with SMTP id m28mr6120730qcr.49.1347445726717; Wed, 12 Sep 2012 03:28:46 -0700 (PDT) Received: by 10.49.71.231 with HTTP; Wed, 12 Sep 2012 03:28:46 -0700 (PDT) Date: Wed, 12 Sep 2012 12:28:46 +0200 Message-ID: Subject: Expected behavior of nested UserGroupInformation From: Bertrand Dechoux To: user@hadoop.apache.org Content-Type: multipart/alternative; boundary=0015175734a8e528bd04c97ea76e --0015175734a8e528bd04c97ea76e Content-Type: text/plain; charset=ISO-8859-1 Hi, I am using UserGroupInformation.doAs(...) in order to launch a job programmatically from a remote application. I was wondering : what is the expected behavior of nested UserGroupInformation? Is it the same as with Jaas? Which is, if I am not mistaken, the last inner 'subject' is used? If that's the case, UserGroupInformation can not be used to enforce that a given code will be executed with the provided user, as the action might nest a inner call with its own user. That might be a security threat if there is not authentication (like Kerberos). Can someone confirm/infirm that? Regards Bertrand --0015175734a8e528bd04c97ea76e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I am using UserGroupInformation.doAs(...) in order to launch a j= ob programmatically from a remote application.
I was wondering : what is= the expected behavior of nested UserGroupInformation?

Is it the sam= e as with Jaas? Which is, if I am not mistaken, the last inner 'subject= ' is used?
If that's the case, UserGroupInformation can not be used to enforce tha= t a given code will be executed with the provided user, as the action might= nest a inner call with its own user.
That might be a security threat if= there is not authentication (like Kerberos).

Can someone confirm/infirm that?

Regards

Bertrand
--0015175734a8e528bd04c97ea76e--