Windows user permissions

Hi,

Maybe someone already faced the problem we are having and found a clever solution, or maybe someone else will benefit from the answers to this topic, so here I am with my problem :slight_smile:

I’m wondering what is the best approach for getting up and running a configuration like the one synthetized below:

  • Every window user have read only permissions on the server
  • This will avoid accidental file deletion or move, with issues for everyone (and yes this keeps happening even if we explicitly warned the artists to do not touch shotgun folders/files manually…)
  • Every time they save something through shotgun, they should be able to do it, even though their window user can’t technically do it, as the permissions are read only.

My initial thought was to extend the hooks that deal with file systems, and the answer from support seems to confirm this direction.
Is this the only way, or there is something smarter that I’m not thinking about?
I’m not an IT guy, so maybe I’m missing something about OS related rules that can avoid us to extend every file writing related hook.

Curious to hear how you guys faced this problem.

Thanks!

3 Likes

Beyond the standard chmod attributes and setting the ‘read only’ flag on files in Windows I haven’t ventured into setting actual windows permissions on files. Each time this topic is discussed internally it goes down a rabbit hole that only has really ugly convoluted solutions so I’d be interested if this is done elsewhere as well.

1 Like

I can certainly understand the desire to lock down the permissions so that changes can only be made through approved processes.

I know this isn’t completely what you are looking for, but if it was me I would probably lock down the folders in the structure right down to the level above the work and publish folder and then allow write permissions from there onwards. That would mean you only need to extend the core hooks as mentioned in this topic.

You could even lock down the permissions on the publish folder as well, and then perhaps you would push the publish copying process out to the farm which would have write permissions, leaving only the work folder open to abuse :slight_smile: .

2 Likes

Hi Philip, I will explore your solution as soon as possible and let you know if it stopped most of our issues.
Thanks again!

2 Likes

I’m finally able to look into this, and after some testing I found out that on windows the file permissions are quite painful to manage, especially if IT is not your specialty :smiley:

It looks like that with the python module pywin32 it’s possible to manage the permissions for windows. Assuming that I will find a satisfying way of doing it, what would be the best way to distribute this python module to everyone? I would like to avoid to put the lib somewhere on the server and add the path to sys.path everytime shotgun desktop is opened…
Any best practice in doing this that is good and follows the Shotgun philosophy?

2 Likes

We don’t have a Shotgun mechanism for managing/distributing python packages.

If you want to avoid storing the module on the server, perhaps you could have a script which could be triggered from a Toolkit hook, that checks if pywin32 could be imported (on windows only) and pip installed pywin32 if it was not found?

2 Likes

Thanks Philip,

you gave me always good ideas :wink:

3 Likes

I’m going to jump on this thread because I’m handling the same problem at our studio right now and have been approaching it from a slightly different direction. It’s very much still a work in progress, but here’s where I’ve gotten after a lot of research and a bit of poking things with sticks.

Instead of working with the hooks to get apps launching correctly, my goal is to get SG Desktop itself launching under the designated write-user’s credentials—if Desktop launches as that user, then every process it creates also launches with the same credentials, which is a nice tidy solution to the problem.

Hypothetically, here’s how I’m hoping to implement that (For the sake of example, I’m going to stay Windows-focused since their permissions are more annoying to deal with than Unix):

  • Create a wrapper executable for Shotgun.exe that handles the launch process. Ideally, users launch this instead of Shotgun.exe, but more on that in a minute
    • Fundamentally, this does a runas and logs in with the desired credentials
    • In our case, the executable would also be fetching those credentials from a central, git-tracked file and decrypting them, which is the main reason I’m doing it in an executable in the first place; I want to keep those credentials as locked-down as possible from the end user while still being able to edit them easily on our end
  • Secondly, since users are bound to launch Shotgun.exe occasionally even if we tell them not to, I’m going to try and take over tk-framework-desktopstartup and insert a bit of my own code into the startup script:
    • On launch, check that the Shotgun process’ user is our write-user
    • If it isn’t, launch our wrapper executable and tear down the current instance. Otherwise, continue launching as usual

There’s the potential for a security exploit in that setup if you’re not careful since it means launching an executable, in a folder the user might have write access to, with elevated permissions. If that’s the strategy we end up using here, I’m absolutely spending the time to make sure that executable is properly validated before launching it.

5 Likes

Well all that sounds very interesting, and possibly easier to maintain.
Are you packing the exe from python distributed as executable?

I think that if this solution works could be a nice and simple way to get around the problem.
The thing about starting the original shotgun instead of the “wrapped one” can be the only issue I see…
But I must say, it all sounds great to me and I would like to know if you have success in implementing it.

Thanks for sharing!

2 Likes

@rootXero Welcome to the forums! and thanks for sharing.
I saw that you wrote into support as well, I ran it past an engineer and I thought it would be better to respond to you here.

For checking if SG Desktop was launched by the wrapper or straight from the exe, the tk-framework-desktopstartup's startup.py would be the right place to do that.

Once you detect that it’s not been launched via your wrapper, you could then launch your wrapper, and then have the main method return 0 (which will trigger a system exit 0 ) and kill the current process.

Best
Phil

4 Likes

With Windows permissions it is possible to give every artist permissions to only add/modify their own files but not delete or move.

That may be a solution which does not involve too much hassle.

I think it would be worth having a Windows Sysadmin look at your fileserver and permission setup. That may be easier than doing this in shotgun.

2 Likes

Thanks so much @philip.scadding (and engineer)! That’s exactly what I needed to know.

And yep, just planning to distribute a python script packed to an exe! I’ll definitely stop back through and update this thread with any progress I make in case it’s helpful for others with similar situations.

In cases where straight permissions updates are a viable setup, that’s absolutely the simplest way to go about it. I’ve been working with our sysadmin through this process to figure out the most elegant way to lock the filer down and unfortunately, for our pipeline’s needs, OS file permissions alone can’t do the job. File ownership isn’t a reliable indicator of who may or may not need to modify a file next, and we need Shotgun to have write access on files that users otherwise should not.

4 Likes

We have currently in place windows permissions like you suggested @Ricardo_Musch, but often times we need to have more control over it :wink:

Will test out the python exe thing one of these days.
Keep us posted @rootXero, thanks!

2 Likes

Another possibility:

Do all your rendering/publishing/copying etc on the farm.

1 Like