Feature #94

slave should set user ID to owner when running tasks

Added by Redmine Admin almost 8 years ago. Updated about 7 years ago.

Status:In progressStart date:
Priority:NormalDue date:
Assignee:Andreas Schröder% Done:


Target version:0.64.6


When a slave runs a task, the effective user ID of the new process is that of whoever started the slave. It should be that of the user who submitted the job, so that the job runs in the same environment as if the user ran it himself.

On Linux, that involves running the slaves as root, and having the slaves call setuid() on the forked processes. I don't know about Windows...


#1 Updated by Andreas Schröder almost 8 years ago

  • Status changed from New to In progress

Isn't this be something which could be set in each job script generator? There are already if-then-constructs where setuid-like commands could be placed.

#2 Updated by Redmine Admin almost 8 years ago

The slave could just run scripts as root, but that would be a major security risk: you would in effect be granting all users super-user access. In fact, it is a security risk even to run the slave as root; it would probably be a good idea in that case to restrict which users are allowed to submit jobs...

#3 Updated by Jorge Daza Garcia-Blanes over 7 years ago

IMHO this can't be done without running the slave as root, which is not an option. So we should find a feasible workaround.

#4 Updated by Andreas Schröder over 7 years ago

  • Tracker changed from Bug to Feature

#5 Updated by Alistair Leslie-Hughes over 7 years ago

Can you provide a scenario to illustrate the need for this?

My understanding if we used setgid, it would allow the slave process to access directories it may not normally be able to. Have I understood it correctly?

#6 Updated by Andreas Schröder over 7 years ago

In my opinion, the master and slave processes should run as a normal user, called for example 'drqueue'. On Gentoo Linux that is done this way. Considering DrQueue's network communication running without authentication and encryption, I would not want to run DrQueue in a production environment as root user.

A warning message could be printed out if somebody tries to start DrQueue as root.

#7 Updated by Andreas Schröder over 7 years ago

  • Target version changed from 0.64.5 to 0.64.6

#8 Updated by Ruben Lopez over 7 years ago

I believe that a safer path would be to use 'sudo' in the render scripts. This has two advantages:
- slaves can be run as a normal user (drqueue for example)
- sysadmins have precise control over what exactly will the slave be able to run as another user. You could,for example, run "sudo myuser xsibatch ..." inside the script, and the /etc/sudoers would only grant drqueue-user permission to become another user when running the XSI renderer. It would even be possible to restrict the set of users which drqueue can become.

There is still a problem: You can easily fake the owner of the job when sending it to the master (using the python lib, for example), but I think that this is a tradeoff that can be left for sysadmins to consider.

#9 Updated by Jorge Daza Garcia-Blanes about 7 years ago

Andreas, give up on this and rollback any changes related.

This cannot be achieved unless drqueue is suid root, that will never be.

The best approach is the sudo (scripting) way of getting that done, and that's a job of improving the renderscripts. It cannot be achieved on the binaries without some suid magic.

Maybe you'd like to get into the scripting road... if not, reject this ticket.

Also available in: Atom PDF