Hi,
See use case background below I have implemented option 2 below. 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 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 set_user to "B" and does a "exec" for the java component 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 > > >
