slave should set user ID to owner when running tasks
|Status:||In progress||Start date:|
|Assignee:||Andreas Schröder||% Done:|
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...
#2 Updated by Redmine Admin about 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...
#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.
#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 over 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.