Securing Workareas

Hi Everyone,

Just wondering if someone can help us with a situation we have been in recently. We have had a requirement to create a fully secure workarea (ie editing, viewing, accessing via network share etc) that is limited to two or three people who have signed confidentiality agreements for the content that they are working on. While they are working on this content no other user is allowed access through any interface as the information they are dealing with is highly sensitive until it is ready to go live.

my question is: How can we fully secure a workarea in a branch for a short period of time so that the developers and producers can work on their content without fear of other users (what ever their teamsite access - Master, Admin etc.) accessing the information.

We tried a number of things without luck:
1) creating a workarea with only a specific group for sharing.... other users could still access and read content.
2) Trying to change ACLs of directories and files... Teamsite changed them back to everyone read, write access.

Are there any other ways to secure a workarea for a short time?

Regards

Raymond van der Zalm
IAG Limited
Sydney, Australia

Find more posts tagged with

Comments

Migrateduser

your #1 approach should have worked when you restricted the group for sharing. How were others able to access the WA?

This is a windows server apparently. Does your iw.cfg file have a webserver_group=TeamSite Web Preview line in it?

And does the TeamSIte Web Preview group contain _only_ the TSIMP_hostname user account?

If the above is true, then only group members should be able to access the WA.

bw

Bob Walden [bob.walden@interwoven.com]
Interwoven Education Group
IM: Yahoo, MSN bob_walden

Wardo

Have you tried to modify submit.cfg? If you can set the ACLs in the WA initially submit.cfg will control how the ACLs are set or changed as files are submitted up thru workflow etc.

rayvdz

Thanks.... I'll give that a try.

Hazzie

Migrateduser

Bob,

I am also looking at trying to secure files using acl's. The reason for doing this is that TeamSite 'as i see it' does not prevent people from editing the files out side of teamsite once you lock them. So if i was to somehow get a mapping to the mount point i could browse to a file using nt explorer and alter it out side of Teamsite.

::BW:

If you use mandatory write lock then yes, TS will stop anyone from modifying a locked file except the lock holder, even via IFS access.

But why do this?

I am currently therefore working on a way of modifying the acls of all the files attached to a job after an author has edited them. I have looked at the win32:FileSecurity module but to be honest the out put from EnumerateRights looks horrendous compared to the output of a callout to calcs.

Has anyone done anywork on modifying acls using cacls.exe before? or should i really use the win32::filesecurity module. If so has nayone any examples of how to store the rights on a file, alter them so no one can modify them, and re enable to the old rights back on the file in case the author needs to re-edit.

I've used cacls, it's got a fairly straightforward syntax, but I haven't done what you're trying to do so I don't have any examples ready. I'm not sure it's the right approach anyway--r u sure mandatory write lock isn't the right way?

Another approach to consider: a frequently-heard issue is that once an author has changed a set of files and they (the files) are awaiting review, how can one guarantee they (the files) are not modified again until after the review is completed. A better way than mandatory write lock or messing with ACLs is to use an updatetask to copy the files into another WA where they are reviewed. This way the author can continue to work on the files in their own work area if needed on new workflow jobs, without changing the versions that are awaiting review. If needed, the review workarea can be created on the fly, just for the purpose of holding the "change set" of files until the review is completed--then after submit, the temp review WA can be deleted.

Just a thought (and not mine, btw: I'm not really a doctor, I just play one online).

bw

Bob Walden [bob.walden@interwoven.com]
Interwoven Education Group
IM: Yahoo, MSN bob_walden

Wardo

Raymond,

Our Submit.cfg file works for controlling ACLs of directories and files when they are submitted up thru workflow.

However, other users can still access and read content within TS. Did Bob's feedback help you solve this?

If so can you please share.

Thanks,

Ward Tongen
Web Administrator
St. Jude Medical, Inc.