AWS Thinkbox Discussion Forums

[8.0] Wide open client install permissions?

I’m wondering why the 8.0 Linux client installer sets the permissions wide open on the entire client installation tree (except the uninstaller).

This allows us to perform an automatic upgrade for you so you won’t need to run the installer again for minor upgrades and service packs.

It’s absolutely safe to lock it down if you have a good solution for running the client installers in a distributed way, so feel free to restrict permissions if you like.

OK. I’m guessing there’s no way to just tell the installer to not open everything up so that we don’t have to correct it retroactively?

Not yet, no. We do for the Repo, but not the client install. The goal is to make sure the system can work if you chose to use it.

Have their been issues with users fiddling with stuff over there? Just asking if there’s other ways to handle concerns. Maybe creating a Deadline user for example that would exist just to do binary updates.

Understood, but it must be apparent that this flies in the face of every systems administrator in the world (and I’m not even one of them).

Not really, no. None of our users are disgruntled enough to start blowing away installation trees yet. :wink: However, I can’'t say I consider “well, no one is having problems with it” to be a worthwhile justification for maintaining the status quo.

A step in the right direction might be to change the ownership of the install to the user Deadline is set to run as, and only give them write permissions to it, since that user will be performing the upgrade process.

For example:

-rwxrwxrwx nobody nobody

would become:

-rwxr-xr-x qmaster nobody

Blindly blowing open the doors just reads as a quick fix in place of a real solution for platforms with *NIX-style permissions.

We do the same on Windows too actually.

I’ll throw it in the dev system so we can discuss making a better solution… Nathan, in your opinion what’s a good way to know the user the Launcher is going to be running as when it’s not running as a service? Like, say user ‘render’ normally runs the launcher, but user ‘bob’ happens to be the one who has it open when the auto-upgrade triggers?

That’s a great question. To me, that seems like even more reinforcement for the idea of providing installer options for setting the ownership and permissions of the installation tree, so that customers at opposite ends of the management/orchestration spectrum can all live in harmony. Right now, the behavior caters exclusively to Bob, and outside of a straightforward solution like that, I highly doubt there’s a silver bullet.

One of the ideas I’ve been bouncing around in my head was the idea of having the Launcher always run as a service while the icons people see in the tray was more of a shell to that. If the service was always running as a defined user we might be able to cater to everyone, but that would be a long ways out.

The nice part there is that the service user would be involved in the upgrade and ‘bob’ wouldn’t be involved, and ‘render’ could just be that service user. I’m sure there are issues with this, more thinking needed.

In the meantime, checkbox along with a warning of what affect it’ll have seems to best short-term solution. I’ll set that up for discussion.

Privacy | Site terms | Cookie preferences