Blender and access to C:

[timbo343]

We have been asked to look into installing blender. First impressions it looks fine until we go to Save As and it shows "Windows C" logged on as a student. When clicking into this students are able to create folders and save their projects to the C of the machine.

 

When we open up blender and save for the first time, it does point to their userareas however we have students here that like to see what they can get access to. If there is no way around this then we may have to put blender on the back burner.

 

Even with Prevent Access to C drive set in group policy, it looks like Blender is overriding this.

 

There are some forums out there that are asking the same question as what i am but there are a lot of answers coming back with "the network manager must be incompetent as blender follows security policies".

 

We cannot set a policy on C to prevent students writing to C as the system requires this write access to function.

 

Anyone got any ideas?

 

EDIT: I see @pluke has had the same issue as me http://www.edugeek.net/forums/educational-software/170098-installing-blender-ms-network.html and may have asked the same question on here: https://blender.stackexchange.com/questions/52438/stopping-blender-seeing-all-system-network-folders-in-campus-school-install

 

Here is a post from the Blender forums. By reading the replies it seems the the blender fan boys are blaming MS https://www.blender.org/forum/viewtopic.php?t=22291

Edited March 26, 2018 by timbo343

[Roberto]

There's two things.

First of all the "policy" you're talking about refers to hiding the drive in explorer. This doesn't secure the drive, it just hides it. It's frankly a bit mickey mouse and not any kind of serious security barrier. We don't bother hiding the drive here for example and its never been an issue.

 

You need to lock down permissions to the c:\ drive, which has always been something that should be done as well as hiding the drive if you wish to keep students away from interfering with it.

 

You say "the system requires this write access to function" , but what specificallyneeds access? Do student accounts need write access? Windows itself doesn't have any requirements for user accounts to write to the root of the c:\ drive, so what does? If you have some kind of staff software that needs users to write to c:\ then you can just give that access to staff. If students really need write access to the root of the c:\ drive then this is a horrific security issue imho regardless of whether or not the drive is hidden, and if that is the case then it's a simple choice, blender or this other thing.

[timbo343]

There's two things.

First of all the "policy" you're talking about refers to hiding the drive in explorer. This doesn't secure the drive, it just hides it. It's frankly a bit mickey mouse and not any kind of serious security barrier. We don't bother hiding the drive here for example and its never been an issue.

 

You need to lock down permissions to the c:\ drive, which has always been something that should be done as well as hiding the drive if you wish to keep students away from interfering with it.

 

You say "the system requires this write access to function" , but what specificallyneeds access? Do student accounts need write access? Windows itself doesn't have any requirements for user accounts to write to the root of the c:\ drive, so what does? If you have some kind of staff software that needs users to write to c:\ then you can just give that access to staff. If students really need write access to the root of the c:\ drive then this is a horrific security issue imho regardless of whether or not the drive is hidden, and if that is the case then it's a simple choice, blender or this other thing.

 

Ok, let me have a look into disabling write access to C for students but im sure i tested this in the past and it broke a few apps that need to write data to the C in the background.

[synaesthesia]

As long as the system user has full access, there should be very little reason for the currently logged on user to have write access. However it's a bigger thing than that, whilst I agree with @Roberto to a point, the people you mentioned in those forums are often quick to judge without having a clue themselves.

It's fine having things locked down but students would still be able to peruse the folders to their heart's content and then find folders they can write to. They'll then invariably save their work there because they can, and moan when it's not available on a different PC.

You'd also therefore need to lock down folder browsing.

[timbo343]

After a small bit of testing, it's only papercut that gives an error - Unable to create the local cache in C:\cache. The program will be started from the network instead.

 

Looks like i will have to see how to re-work this.

[Arthur]

it's only papercut that gives an error - Unable to create the local cache in C:\cache.

Could you specify a different folder using the --cache parameter?

 

https://www.papercut.com/products/ng/manual/clienttool/topics/user-client-install-windows.html

[timbo343]

Could you specify a different folder using the --cache parameter?

 

https://www.papercut.com/products/ng/manual/clienttool/topics/user-client-install-windows.html

 

I thought that as this might be the only other alternative now after reading the following line:

 

Using pc-client-local-cache.exe is recommended on large networks. It does, however, require a globally writable cache directory. By default, the cache is created in a directory on the system drive (normally C:\Cache). You can specify an alternate cache with the --cache command-line switch. Administrators should ensure that standard users have write access to the system drive, or manually create the cache directory if required.

[Roberto]

We dump our local cache for papercut into c:\programdata\papercutclient and haven't had problems. If you're worried about students keeping bad things in that folder then a quick delete and re-create of that folder in a computer startup script won't be a problem, or maybe delete *.* from that folder with a logout script if you need to keep things really tight.

.

[timbo343]

I was thinking about just using the pc-client.exe version (the network one) as we delete the Cache folder at shutdown and logoff as there was a point where it was causing a few little errors. Thinking about the way we are doing it already by deleting the cache folder, we are essentially pulling down the exe from the server at every logon.

 

I will test the pc-client.exe version and see about re-directing the cache folder somewhere else if we are to continue to use the local cache option.