I'm re-reading all of your prior messages (we're all volunteers here, so
please be patient before resending messages asking for more prompt
help). I'm confused as to your original goal.
You say you're using the Slider upgrade command to dynamically launch a
new container in a Slider application on-demand? Why not just launch a
new Slider application when a new user requests your service.
Also, you mentioned a couple of places where you thought the code was
doing something incorrectly. Please feel free to create JIRA issues and
provide a test+patch for the change you think would be better.
Manoj Samel wrote:
Hello Again !
One more observation .. hopefully that triggers some feedback from this
forum ...
1) Without the setuid option, the component Execute() command is "java -Dxx
-cp yy abc" etc. This runs fine. On the node running the component, I can
see this process as well its parent process as "/bin/bash --login -c java
-Dxx -cp yy abc" etc. So all is good and parent process is the shell as
expected
2) With the setuid option, the component Execute() command is not java but
the path to my C executable and its parameters e.g. "/a/b/processlauncher
arg1 arg2". When I run this, the parent of this dies quickly -- but I was
able to capture the parent process before it dies. The parent is NOT
"/bin/bash --login -c " as I was expecting but is "/usr/bin/python -S<path
to component script.py> START
/xxx/application_1461117905837_0276/container_e13_1461117905837_0276_01_000002/command-2.json
/xxx/appcache/application_1461117905837_0276/filecache/11/spas-1.0.0.zip/package
/xyz/application_1461117905837_0276/container_e13_1461117905837_0276_01_000002/structured-out-2.json
INFO
/foo/application_1461117905837_0276/container_e13_1461117905837_0276_01_000002
It appears that when the component is a executable, rather than Java (as
was in case 1), it is run as Python script ! Any idea why ? Could this be
reason why the parent process is dying quickly ?
I also tried this with a simple C program as component that does nothing
but loops infinitely. I.e. without it being setuid or doing other execle()
etc. Even with the simple C binary, I see above behavior. So something
different about using a executable rather than Java command as component
??? Should I execute the C binary component in different manner ?
Any guidance on this will be really appreciated !!!!
Thanks,
Manoj
---------- Forwarded message ----------
From: Manoj Samel<manojsamelt...@gmail.com>
Date: Thu, Apr 21, 2016 at 2:40 PM
Subject: Need Help !: Run each component of application as different user
To: dev@slider.incubator.apache.org
Hi,
See use case background below
I have implemented option 2 mentioned below (as a C program deployed on
nodes as setuid root binary). Need help in debugging issue I am seeing
Without the setuid option, the execution is
1. Launch Slider AM as user "A"
2. Launch java component using command like "java -cp ....". These run as
user "A" as well. Things run well
With setuid root option, the execution is
1. Launch slider AM as user "A" as before
2. Instead of launching java program as the component, launch the setuid
program as a component. The program gets the end user name , say "B" as
parameter. It does a setuid() and setgid() to user "B" (remember, its
running as setuid root) and does a "execle()" for the java component,
setting java parameters etc.
The component comes up fine but I noticed that the "status" command fails
... Digging further, it seems that the parent process dies when I use the
setuid
With the normal execution, I noticed that there are two processes launched
for a component on a node. The first process is "/bin/bash --login -c java
..." coming from my Execute() (which is traced to sliders
resource_management/core/shell.py. The child process then is "java xxx".
User for both processes is user "A"
With the setuid execution, the parent process dies quickly. The child
process gets orphaned and gets parent process ID as 1 (and is running as
user "B")
Any help in identifying why is the parent process dying ?
Thanks in advance !!
Manoj
PS : Please ignore my last mail sent with same title few minutes back. I
hit return by mistake when it was not complete :(
On Fri, Apr 8, 2016 at 10:30 AM, Manoj Samel<manojsamelt...@gmail.com>
wrote:
Hello,
Environment is slider .80 on Hadoop 2.6 secured cluster
A component is launched for each distinct user of the service (via
upgrade). E.g. when user A accesses service, do a "upgrade" and create a
component for user A. When user B comes, create another component for user
B etc.
At present, all of these components are launched& run as single linux
user. What are the options to run each component as different user ?
Following are couple of options I can think of, each involving starting as
root and then setting the uid / gid to the desired user
1. Launch the java command using "sudo". Then at the start, the Java
program sets its real uid to the target user (passed as option to program)
using a small C function used as JNI call. From then on, it runs as that
effective user for rest of its life. One open research question is - Since
sudo has to be run by a non-root user, then the sudoer need to be updated
to allow this without password. Not yet sure what command should the sudoer
should contain, as this is launched by python class.
2. Have a C executable that is setUID root. Launch this executable as
component (with user as one of the parameter). The first thing it does is
drops its UID to the target user and then does a exec "java xxx", running
java as the target user
Any other out-of-box options ?
In resource_management/core/resources/system.py, I noticed that class
Execute can take a parameter "user"< user = ResourceArgument()>. Its not
clear if and how this could be used. In core/shell.py, the logic around
"user" is commented out with comment " Do not su to the supplied user" ..
Any feedback on approach / pros / cons / potential issues will be
appreciated !
Thanks,
Manoj
