You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bigtop.apache.org by "Martin Bukatovic (JIRA)" <ji...@apache.org> on 2014/05/30 08:08:01 UTC

[jira] [Updated] (BIGTOP-1326) iTest Shell does fully work under root user only

     [ https://issues.apache.org/jira/browse/BIGTOP-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Bukatovic updated BIGTOP-1326:
-------------------------------------

    Description: 
When you specify different effective user for a shell object, eg: 

{noformat}
Shell shHDFS = new Shell("/bin/bash", "hdfs")
{noformat}

It will try to run the following command to do it:

{noformat}
sudo -u hdfs PATH=$PATH /bin/bash
{noformat}

For reference, this is defined in {{bigtop-test-framework/src/main/groovy/org/apache/bigtop/itest/shell/Shell.groovy}} on by:

{noformat}
def proc = user ? "sudo -u $user PATH=${System.getenv('PATH')} $shell".execute() : "$shell".execute()
{noformat}

This means that without further sudo configuration, such code would only work if you are running it under root (edited for clarity).

To run it under user {{bigtop}} who is single member of group bigtop, you need
to add the following sudo configuration file into {{/etc/sudoers.d}} directory:

{noformat}
Defaults    env_keep += "PATH"
Defaults    exempt_group = bigtop

bigtop  ALL= (root) NOPASSWD: /bin/bash
bigtop  ALL= (hdfs) NOPASSWD: /bin/bash
{noformat}

The first two lines allows bigtop user to pass PATH env variable to process
executed via sudo.

Since sudo (and for quite good reasons) redefines enviroment variables of the
process it executes (see {{env_reset}} sudoers option) and morevoer sets PATH to
predefined safe value (see {{secure_path}} sudoers option), first two lines are
needed:

 * first line allows passing PATH in general, but it doesn't have any effect
   alone alone because of {{secure_path}} which always redefines it anyway
 * second line allows users of group bigtop to pass or redefine PATH enviroment
   variable, but it doesn't work without the first line

In addition, when you do this sudo configuration, you don't need to set PATH
explicitelly as done in previous example, but the PATH is passed by default
(but only for members of bigtop group), so this is enough:

{noformat}
sudo -u hdfs /bin/bash
{noformat}

On the other hand we can't remove explicit passing of PATH variable, because
it would break it for the root user.

So I propose the following:

 * discuss this if workflow is ok to be declared as official way how to use
   iTest shell object under non root users
 * then I will attach a patch for documention this in some README file
   (any ideas where it would be best to add it?)
 * does it make sense to run most of the bigtop tests under non root user until there is a good reason to use another one? I think that running tests under root user by default is not optimal because of the complexity of hadoop environment.


  was:
When you specify different effective user for a shell object, eg: 

{noformat}
Shell shHDFS = new Shell("/bin/bash", "hdfs")
{noformat}

It will try to run the following command to do it:

{noformat}
sudo -u hdfs PATH=$PATH /bin/bash
{noformat}

For reference, this is defined in {{bigtop-test-framework/src/main/groovy/org/apache/bigtop/itest/shell/Shell.groovy}} on by:

{noformat}
def proc = user ? "sudo -u $user PATH=${System.getenv('PATH')} $shell".execute() : "$shell".execute()
{noformat}

This means that such code would only work if you are running it under root.

To run it under user {{bigtop}} who is single member of group bigtop, you need
to add the following sudo configuration file into {{/etc/sudoers.d}} directory:

{noformat}
Defaults    env_keep += "PATH"
Defaults    exempt_group = bigtop

bigtop  ALL= (root) NOPASSWD: /bin/bash
bigtop  ALL= (hdfs) NOPASSWD: /bin/bash
{noformat}

The first two lines allows bigtop user to pass PATH env variable to process
executed via sudo.

Since sudo (and for quite good reasons) redefines enviroment variables of the
process it executes (see {{env_reset}} sudoers option) and morevoer sets PATH to
predefined safe value (see {{secure_path}} sudoers option), first two lines are
needed:

 * first line allows passing PATH in general, but it doesn't have any effect
   alone alone because of {{secure_path}} which always redefines it anyway
 * second line allows users of group bigtop to pass or redefine PATH enviroment
   variable, but it doesn't work without the first line

In addition, when you do this sudo configuration, you don't need to set PATH
explicitelly as done in previous example, but the PATH is passed by default
(but only for members of bigtop group), so this is enough:

{noformat}
sudo -u hdfs /bin/bash
{noformat}

On the other hand we can't remove explicit passing of PATH variable, because
it would break it for the root user.

So I propose the following:

 * discuss this if workflow is ok to be declared as official way how to use
   iTest shell object under non root users
 * then I will attach a patch for documention this in some README file
   (any ideas where it would be best to add it?)
 * does it make sense to run most of the bigtop tests under non root user until there is a good reason to use another one? I think that running tests under root user by default is not optimal because of the complexity of hadoop environment.



> iTest Shell does fully work under root user only
> ------------------------------------------------
>
>                 Key: BIGTOP-1326
>                 URL: https://issues.apache.org/jira/browse/BIGTOP-1326
>             Project: Bigtop
>          Issue Type: Bug
>          Components: Tests
>    Affects Versions: 0.8.0
>            Reporter: Martin Bukatovic
>
> When you specify different effective user for a shell object, eg: 
> {noformat}
> Shell shHDFS = new Shell("/bin/bash", "hdfs")
> {noformat}
> It will try to run the following command to do it:
> {noformat}
> sudo -u hdfs PATH=$PATH /bin/bash
> {noformat}
> For reference, this is defined in {{bigtop-test-framework/src/main/groovy/org/apache/bigtop/itest/shell/Shell.groovy}} on by:
> {noformat}
> def proc = user ? "sudo -u $user PATH=${System.getenv('PATH')} $shell".execute() : "$shell".execute()
> {noformat}
> This means that without further sudo configuration, such code would only work if you are running it under root (edited for clarity).
> To run it under user {{bigtop}} who is single member of group bigtop, you need
> to add the following sudo configuration file into {{/etc/sudoers.d}} directory:
> {noformat}
> Defaults    env_keep += "PATH"
> Defaults    exempt_group = bigtop
> bigtop  ALL= (root) NOPASSWD: /bin/bash
> bigtop  ALL= (hdfs) NOPASSWD: /bin/bash
> {noformat}
> The first two lines allows bigtop user to pass PATH env variable to process
> executed via sudo.
> Since sudo (and for quite good reasons) redefines enviroment variables of the
> process it executes (see {{env_reset}} sudoers option) and morevoer sets PATH to
> predefined safe value (see {{secure_path}} sudoers option), first two lines are
> needed:
>  * first line allows passing PATH in general, but it doesn't have any effect
>    alone alone because of {{secure_path}} which always redefines it anyway
>  * second line allows users of group bigtop to pass or redefine PATH enviroment
>    variable, but it doesn't work without the first line
> In addition, when you do this sudo configuration, you don't need to set PATH
> explicitelly as done in previous example, but the PATH is passed by default
> (but only for members of bigtop group), so this is enough:
> {noformat}
> sudo -u hdfs /bin/bash
> {noformat}
> On the other hand we can't remove explicit passing of PATH variable, because
> it would break it for the root user.
> So I propose the following:
>  * discuss this if workflow is ok to be declared as official way how to use
>    iTest shell object under non root users
>  * then I will attach a patch for documention this in some README file
>    (any ideas where it would be best to add it?)
>  * does it make sense to run most of the bigtop tests under non root user until there is a good reason to use another one? I think that running tests under root user by default is not optimal because of the complexity of hadoop environment.



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