Forgot to mention some digging I did ... initially to check the status
check failures ...
In the component's python management script, for the status check call, I
had the status use the check_process_status() function provided by slider
and used in many examples ; like below ...
def status(self, env):
import xyz
env.set_params(xyz)
logger = self.getLogger()
logger.info('*** method = status ***')
check_process_status(xyz.pid_file)
def start(self, env):
import xyz
env.set_params(xyz)
self.configure(env)
Execute( ..... )
Looking into check_process_status() implementation in
resource_management/libraries/functions/check_process_status.py; it reads
the pid file, gets the PID from it and does a kill(pid,0) on it to check
process status.
1) I think this check is not comprehensive. kill 0 can be sent to any
process belonging to that user. It does not need to be the component
process. E.g. if the component dies and another process started by that
user on cluster gets the same PID, the kill (pid,0) will succeed, which it
should not in this case. I think this should be tightened ...
2) When I switched the user running the component by using the setuid
option I mentioned, I thought the kill(pid,0) will fail since parent
process is the user who launched initial component process using "bash
--login -c xxx" (which is same as user who launches the slider AM) and
child process user is switched to some other user using the setuid program.
kill 0 to another users process will fail. Hence I changed the status()
method in my components python script to do my own check. The parent
process still dies ...
Is it correct to assume that the status check is done by the parent process
which is "/bin/bash --login ..." and which launches a subprocess as
specified in execute(). Can someone confirm this ?
On Thu, Apr 21, 2016 at 2:40 PM, Manoj Samel <manojsamelt...@gmail.com>
wrote:
> 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
>>
>>
>>
>
