Hi Manoj, The "/usr/bin/python -S <path to component script.py> START ..." command looks normal; that is how the component scripts are executed. I would expect this to be the parent of the "/bin/bash --login -c <Execute command>" process. If you're seeing the python as the parent of the Execute command, it is probably not why your process is failing. One thing you can do is add logoutput=True to your Execute command; maybe that will show you the error that is happening.
I wonder if the problem is related to the use of execle. I understand that exec commands replace the current process rather than creating a child process, like the system command would. Perhaps if you used the system command in your C code, that would produce a different result. Billie On Fri, Apr 22, 2016 at 12:17 PM, Manoj Samel <manojsamelt...@gmail.com> 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 > > > > > > >
