Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
0.8.0
-
None
Description
When you specify different effective user for a shell object, eg:
Shell shHDFS = new Shell("/bin/bash", "hdfs")
It will try to run the following command to do it:
sudo -u hdfs PATH=$PATH /bin/bash
For reference, this is defined in bigtop-test-framework/src/main/groovy/org/apache/bigtop/itest/shell/Shell.groovy on by:
def proc = user ? "sudo -u $user PATH=${System.getenv('PATH')} $shell".execute() : "$shell".execute()
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:
Defaults env_keep += "PATH" Defaults exempt_group = bigtop bigtop ALL= (root) NOPASSWD: /bin/bash bigtop ALL= (hdfs) NOPASSWD: /bin/bash
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:
sudo -u hdfs /bin/bash
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.
Attachments
Attachments
Issue Links
- is required by
-
BIGTOP-1307 Some TestCLI cases fail with 'No such file or directory'
- Resolved
1.
|
Puppet should provision sudoers to allow NOPASSWD test user | Open | Unassigned |