Re: limit access to workgroup

[Vladimir Jankijevic]

the problem with that is, if you can read, you can copy :) One way or
another :)

if you don't mind copying, then give read only access, no?


On Tue, Jul 9, 2013 at 12:22 PM, Martin  wrote:

> Hi list,
>
> This isn't exactly an SI question but I was wondering if there is any way
> to limit direct access to a SI Workgroup allocated in a server so it could
> be used by SI, but not copied or altered.
>
> Martin
>



-- 
---
Vladimir Jankijevic
Technical Direction

Elefant Studios AG
Lessingstrasse 15
CH-8002 Zürich

+41 44 500 48 20

www.elefantstudios.ch
---

Re: limit access to workgroup

[Rob Wuijster]

Not sure if SI likes it, but you could make the WG folder read only?
Depending on the server OS, you have to take care of users roles and such.
Shouldn't be that hard I guess.


Rob

\/-\/\/

On 9-7-2013 12:22, Martin wrote:

Hi list,

This isn't exactly an SI question but I was wondering if there is any 
way to limit direct access to a SI Workgroup allocated in a server so 
it could be used by SI, but not copied or altered.


Martin

No virus found in this message.
Checked by AVG - www.avg.com 
Version: 2013.0.3349 / Virus Database: 3204/6475 - Release Date: 07/08/13

Re: limit access to workgroup

[Sandy Sutherland]

As fas I know SI does not write into the WG folder - so you should be 
able to set user based permissions on the folder so that your admin can 
read and write, while all the std users can only read - but as mentioned 
here if they can read, then they can copy!


S.

On 2013/07/09 11:34 AM, Rob Wuijster wrote:

Not sure if SI likes it, but you could make the WG folder read only?
Depending on the server OS, you have to take care of users roles and such.
Shouldn't be that hard I guess.
Rob

\/-\/\/
On 9-7-2013 12:22, Martin wrote:

Hi list,

This isn't exactly an SI question but I was wondering if there is any 
way to limit direct access to a SI Workgroup allocated in a server so 
it could be used by SI, but not copied or altered.


Martin

No virus found in this message.
Checked by AVG - www.avg.com 
Version: 2013.0.3349 / Virus Database: 3204/6475 - Release Date: 07/08/13

Re: limit access to workgroup

[Raffaele Fragapane]

"not copied" is impossible. If your concern is code protection then you
have to look at code protection problems and solutions and not at file
management or DCC client solutions.

Use of compiled files only (Python binary compiles are trivial to reverse
but they will be pretty annoying to read and rip as the interpreter strips
off a lot of crud) and the such.

If your concern is pollution (people writing crap in it) just make sure the
filer end of things is properly managed. User groups and such. How that's
done is almost entirely dependent on what solutions you use for storage and
file management over there.


On Tue, Jul 9, 2013 at 8:22 PM, Martin  wrote:

> Hi list,
>
> This isn't exactly an SI question but I was wondering if there is any way
> to limit direct access to a SI Workgroup allocated in a server so it could
> be used by SI, but not copied or altered.
>
> Martin
>



-- 
Our users will know fear and cower before our software! Ship it! Ship it
and let them flee like the dogs they are!

RE: limit access to workgroup

[Matt Lind]

Depends on your goals/needs:

If you're trying to set up a renderfarm and have a workgroup set up to be used 
by the nodes, then just put the workgroup on a machine where users cannot reach 
it.

If you're trying to set up a workgroup to be used by users in main production, 
then you really can't hide the workgroup as Softimage operates under the same  
user permissions as the user.  The best you can do is make the workgroup 
read-only.

One thing you could try is an old-school method that was employed before the 
existence of workgroups - write your tools as script functions in files instead 
of self installing plugins.  The concept is to write a master wrapper command 
that acts as a front end to call all the other commands using 
Application.ExecuteCommand() or Application.ExecuteScript() or 
Application.ExecuteScriptCode().  The scripts can be placed on any server away 
from user direct access, or can even be embedded in a database table which is 
called dynamically.   There will be a slight hiccup while the plugin looks for 
the command to execute in the database table, but it completely hides the 
location of the script preventing user tampering unless they're quite adept at 
scripting to extract whatever it is you're protecting.

The technique I use is to brute force replace the contents of the workgroup on 
application startup.  I intended this to be a way to ensure users all have the 
latest versions of the tools, but it has a beneficial side effect of 
frustrating users enough they don't bother tampering with the workgroup because 
they know any modifications they make are only valid as long as the current 
session.  Next restart and all their changes are wiped.



Matt






From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Martin
Sent: Tuesday, July 09, 2013 3:22 AM
To: softimage@listproc.autodesk.com
Subject: limit access to workgroup

Hi list,

This isn't exactly an SI question but I was wondering if there is any way to 
limit direct access to a SI Workgroup allocated in a server so it could be used 
by SI, but not copied or altered.

Martin

Re: limit access to workgroup

[Martin]

My main goal was to share a Workgroup folder for main production, and we
have some not compiled (jscript, python, vbs) plugins that we don't want to
be copied, specially if we are going to have outsource temporal workers
helping us. I'll have to look for another solution. Code protection sounds
like a very troublesome task.

Matt's suggestion sounds interesting, I'll give it a shot. Thanks.

Thanks again,

Martin


On Wed, Jul 10, 2013 at 9:01 AM, Matt Lind  wrote:

> Depends on your goals/needs:
>
> ** **
>
> If you’re trying to set up a renderfarm and have a workgroup set up to be
> used by the nodes, then just put the workgroup on a machine where users
> cannot reach it.
>
> ** **
>
> If you’re trying to set up a workgroup to be used by users in main
> production, then you really can’t hide the workgroup as Softimage operates
> under the same  user permissions as the user.  The best you can do is make
> the workgroup read-only.
>
> ** **
>
> One thing you could try is an old-school method that was employed before
> the existence of workgroups - write your tools as script functions in files
> instead of self installing plugins.  The concept is to write a master
> wrapper command that acts as a front end to call all the other commands
> using Application.ExecuteCommand() or Application.ExecuteScript() or
> Application.ExecuteScriptCode().  The scripts can be placed on any server
> away from user direct access, or can even be embedded in a database table
> which is called dynamically.   There will be a slight hiccup while the
> plugin looks for the command to execute in the database table, but it
> completely hides the location of the script preventing user tampering
> unless they’re quite adept at scripting to extract whatever it is you’re
> protecting.
>
> ** **
>
> The technique I use is to brute force replace the contents of the
> workgroup on application startup.  I intended this to be a way to ensure
> users all have the latest versions of the tools, but it has a beneficial
> side effect of frustrating users enough they don’t bother tampering with
> the workgroup because they know any modifications they make are only valid
> as long as the current session.  Next restart and all their changes are
> wiped.
>
> ** **
>
> ** **
>
> ** **
>
> Matt
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Martin
> *Sent:* Tuesday, July 09, 2013 3:22 AM
> *To:* softimage@listproc.autodesk.com
> *Subject:* limit access to workgroup
>
> ** **
>
> Hi list,
>
> ** **
>
> This isn't exactly an SI question but I was wondering if there is any way
> to limit direct access to a SI Workgroup allocated in a server so it could
> be used by SI, but not copied or altered.
>
> ** **
>
> Martin
>

Re: limit access to workgroup

[Raffaele Fragapane]

Can I ask on what grounds?
It's very hard to think of something you could write in Python (let alone
in JS or VBS) that, without the company's infrastructure, would represent
enough of an edge to be protected so fiercely.
Unless it's a security risk, and not the "theft" of the tools worrying
somebody.

I've seen it fairly frequently where some places got fairly protective
about some stuff that without the asset/infrastructure was downright
useless, or that was held in high regard but really was so incredibly
trivial that the round-about ways taken to protect it got quite laughable.

You can always offer only the pyc compiles for most of the stuff anyway, so
all they would get is bytecode. Reversible, admittedly, but again, is it
really such hot property that it's worth protecting?


On Wed, Jul 10, 2013 at 2:25 PM, Martin  wrote:

> My main goal was to share a Workgroup folder for main production, and we
> have some not compiled (jscript, python, vbs) plugins that we don't want to
> be copied, specially if we are going to have outsource temporal workers
> helping us. I'll have to look for another solution. Code protection sounds
> like a very troublesome task.
>
> Matt's suggestion sounds interesting, I'll give it a shot. Thanks.
>
> Thanks again,
>
> Martin
>
>
> On Wed, Jul 10, 2013 at 9:01 AM, Matt Lind wrote:
>
>> Depends on your goals/needs:
>>
>> ** **
>>
>> If you’re trying to set up a renderfarm and have a workgroup set up to be
>> used by the nodes, then just put the workgroup on a machine where users
>> cannot reach it.
>>
>> ** **
>>
>> If you’re trying to set up a workgroup to be used by users in main
>> production, then you really can’t hide the workgroup as Softimage operates
>> under the same  user permissions as the user.  The best you can do is make
>> the workgroup read-only.
>>
>> ** **
>>
>> One thing you could try is an old-school method that was employed before
>> the existence of workgroups - write your tools as script functions in files
>> instead of self installing plugins.  The concept is to write a master
>> wrapper command that acts as a front end to call all the other commands
>> using Application.ExecuteCommand() or Application.ExecuteScript() or
>> Application.ExecuteScriptCode().  The scripts can be placed on any server
>> away from user direct access, or can even be embedded in a database table
>> which is called dynamically.   There will be a slight hiccup while the
>> plugin looks for the command to execute in the database table, but it
>> completely hides the location of the script preventing user tampering
>> unless they’re quite adept at scripting to extract whatever it is you’re
>> protecting.
>>
>> ** **
>>
>> The technique I use is to brute force replace the contents of the
>> workgroup on application startup.  I intended this to be a way to ensure
>> users all have the latest versions of the tools, but it has a beneficial
>> side effect of frustrating users enough they don’t bother tampering with
>> the workgroup because they know any modifications they make are only valid
>> as long as the current session.  Next restart and all their changes are
>> wiped.
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> Matt
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> *From:* softimage-boun...@listproc.autodesk.com [mailto:
>> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Martin
>> *Sent:* Tuesday, July 09, 2013 3:22 AM
>> *To:* softimage@listproc.autodesk.com
>> *Subject:* limit access to workgroup
>>
>> ** **
>>
>> Hi list,
>>
>> ** **
>>
>> This isn't exactly an SI question but I was wondering if there is any way
>> to limit direct access to a SI Workgroup allocated in a server so it could
>> be used by SI, but not copied or altered.
>>
>> ** **
>>
>> Martin
>>
>
>


-- 
Our users will know fear and cower before our software! Ship it! Ship it
and let them flee like the dogs they are!

Re: limit access to workgroup

[Martin]

We are a small company, and we have some tools that aren't really that
great, but the company's owner is asking me if we could do something to
protect them. For me they are simple code, but for him they are property of
the company.

I understand him but I don't think protecting all of our simple scripts
would worth the trouble, so I may end up convincing him to just give up or
hire a specialist.

In my previous work, the chief programmer used to protect all the compiled
tools with some sort of intranet authentication so the tools could only be
used when the PC is connected to the company's LAN. I didn't want to do
that because I would have to rewrite every vbs and js files to something
compilable, so I was wondering if it could be done at file management level.

Me, I just want to protect the files to avoid pollution. One time I had a
designer complaining that some script I wrote wasn't working, and when I
opened the script file, it was blank. It seems that he opened the file in
the script editor, who knows why deleted everything and when he was closing
SI just clicked on save.

Martin


On Wed, Jul 10, 2013 at 1:44 PM, Raffaele Fragapane <
raffsxsil...@googlemail.com> wrote:

> Can I ask on what grounds?
> It's very hard to think of something you could write in Python (let alone
> in JS or VBS) that, without the company's infrastructure, would represent
> enough of an edge to be protected so fiercely.
> Unless it's a security risk, and not the "theft" of the tools worrying
> somebody.
>
> I've seen it fairly frequently where some places got fairly protective
> about some stuff that without the asset/infrastructure was downright
> useless, or that was held in high regard but really was so incredibly
> trivial that the round-about ways taken to protect it got quite laughable.
>
> You can always offer only the pyc compiles for most of the stuff anyway,
> so all they would get is bytecode. Reversible, admittedly, but again, is it
> really such hot property that it's worth protecting?
>
>
> On Wed, Jul 10, 2013 at 2:25 PM, Martin  wrote:
>
>> My main goal was to share a Workgroup folder for main production, and we
>> have some not compiled (jscript, python, vbs) plugins that we don't want to
>> be copied, specially if we are going to have outsource temporal workers
>> helping us. I'll have to look for another solution. Code protection sounds
>> like a very troublesome task.
>>
>> Matt's suggestion sounds interesting, I'll give it a shot. Thanks.
>>
>> Thanks again,
>>
>> Martin
>>
>>
>> On Wed, Jul 10, 2013 at 9:01 AM, Matt Lind wrote:
>>
>>> Depends on your goals/needs:
>>>
>>> ** **
>>>
>>> If you’re trying to set up a renderfarm and have a workgroup set up to
>>> be used by the nodes, then just put the workgroup on a machine where users
>>> cannot reach it.
>>>
>>> ** **
>>>
>>> If you’re trying to set up a workgroup to be used by users in main
>>> production, then you really can’t hide the workgroup as Softimage operates
>>> under the same  user permissions as the user.  The best you can do is make
>>> the workgroup read-only.
>>>
>>> ** **
>>>
>>> One thing you could try is an old-school method that was employed before
>>> the existence of workgroups - write your tools as script functions in files
>>> instead of self installing plugins.  The concept is to write a master
>>> wrapper command that acts as a front end to call all the other commands
>>> using Application.ExecuteCommand() or Application.ExecuteScript() or
>>> Application.ExecuteScriptCode().  The scripts can be placed on any server
>>> away from user direct access, or can even be embedded in a database table
>>> which is called dynamically.   There will be a slight hiccup while the
>>> plugin looks for the command to execute in the database table, but it
>>> completely hides the location of the script preventing user tampering
>>> unless they’re quite adept at scripting to extract whatever it is you’re
>>> protecting.
>>>
>>> ** **
>>>
>>> The technique I use is to brute force replace the contents of the
>>> workgroup on application startup.  I intended this to be a way to ensure
>>> users all have the latest versions of the tools, but it has a beneficial
>>> side effect of frustrating users enough they don’t bother tampering with
>>> the workgroup because they know any modifications they make are only valid
>>> as long as the current session.  Next restart and all their changes are
>>> wiped.
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> Matt
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> *From:* softimage-boun...@listproc.autodesk.com [mailto:
>>> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Martin
>>> *Sent:* Tuesday, July 09, 2013 3:22 AM
>>> *To:* softimage@listproc.autodesk.com
>>> *Subject:* limit access to workgroup
>>>
>>> ** **
>>>
>>> Hi list,
>>>
>>> ** **
>>>
>>> This isn't exactly an SI question but I was wondering if there is any
>>> way t

Re: limit access to workgroup

[Raffaele Fragapane]

In that case I would recommend you prevent contamination and destruction at
a filer level through permissions tied to groups, and try to convince the
owner the effort of protecting trivialities added to the missed
productivity of not offering them to the users usually far out-costs the
damage of having simple scripts stolen.

It'd be a different deal if security was involved, IE: scripts and hacks
that if seen in plain text could compromise access or data (horrible things
such as plain text passwords), but unless you have some truly novel
algorithmic worth prototyped in plain text somewhere in a python file,
usually scripts contain a topmost layer that is irrelevant without the
infrastructure, or perform tasks that if someone stole such productivity
boosters would hardly lose you clients to the thief.

As I said, for Python you can move a fair chunk of stuff to pyc only and
introduce a thin (but for most non tech savy users already impregnable)
barrier.
If someone steals something written in VBS I have it on good ground they
usually die of some horrible skin disease within the year anyway, so that
takes care of itself.

JS you will just have to live with it having been stolen. You got anything
critical written in JS?



On Wed, Jul 10, 2013 at 3:14 PM, Martin  wrote:

> We are a small company, and we have some tools that aren't really that
> great, but the company's owner is asking me if we could do something to
> protect them. For me they are simple code, but for him they are property of
> the company.
>
> I understand him but I don't think protecting all of our simple scripts
> would worth the trouble, so I may end up convincing him to just give up or
> hire a specialist.
>
> In my previous work, the chief programmer used to protect all the compiled
> tools with some sort of intranet authentication so the tools could only be
> used when the PC is connected to the company's LAN. I didn't want to do
> that because I would have to rewrite every vbs and js files to something
> compilable, so I was wondering if it could be done at file management level.
>
> Me, I just want to protect the files to avoid pollution. One time I had a
> designer complaining that some script I wrote wasn't working, and when I
> opened the script file, it was blank. It seems that he opened the file in
> the script editor, who knows why deleted everything and when he was closing
> SI just clicked on save.
>
> Martin
>
>
> On Wed, Jul 10, 2013 at 1:44 PM, Raffaele Fragapane <
> raffsxsil...@googlemail.com> wrote:
>
>> Can I ask on what grounds?
>> It's very hard to think of something you could write in Python (let alone
>> in JS or VBS) that, without the company's infrastructure, would represent
>> enough of an edge to be protected so fiercely.
>> Unless it's a security risk, and not the "theft" of the tools worrying
>> somebody.
>>
>> I've seen it fairly frequently where some places got fairly protective
>> about some stuff that without the asset/infrastructure was downright
>> useless, or that was held in high regard but really was so incredibly
>> trivial that the round-about ways taken to protect it got quite laughable.
>>
>> You can always offer only the pyc compiles for most of the stuff anyway,
>> so all they would get is bytecode. Reversible, admittedly, but again, is it
>> really such hot property that it's worth protecting?
>>
>>
>> On Wed, Jul 10, 2013 at 2:25 PM, Martin  wrote:
>>
>>> My main goal was to share a Workgroup folder for main production, and we
>>> have some not compiled (jscript, python, vbs) plugins that we don't want to
>>> be copied, specially if we are going to have outsource temporal workers
>>> helping us. I'll have to look for another solution. Code protection sounds
>>> like a very troublesome task.
>>>
>>> Matt's suggestion sounds interesting, I'll give it a shot. Thanks.
>>>
>>> Thanks again,
>>>
>>> Martin
>>>
>>>
>>> On Wed, Jul 10, 2013 at 9:01 AM, Matt Lind wrote:
>>>
 Depends on your goals/needs:

 ** **

 If you’re trying to set up a renderfarm and have a workgroup set up to
 be used by the nodes, then just put the workgroup on a machine where users
 cannot reach it.

 ** **

 If you’re trying to set up a workgroup to be used by users in main
 production, then you really can’t hide the workgroup as Softimage operates
 under the same  user permissions as the user.  The best you can do is make
 the workgroup read-only.

 ** **

 One thing you could try is an old-school method that was employed
 before the existence of workgroups - write your tools as script functions
 in files instead of self installing plugins.  The concept is to write a
 master wrapper command that acts as a front end to call all the other
 commands using Application.ExecuteCommand() or Application.ExecuteScript()
 or Application.ExecuteScriptCode().  The scripts can be placed on any
 server away from user direct access,