Issue with permissions on files and folders

Env: Teamsite 7.3, Windows 2008 R2

I am facing two issues

1. Group on a file/folder created under wokrarea is not same as workarea group.

I have gone through many devnet articles and am aware of the sticky bit in unix/solaris. We being in windows environment, is there any way I can enforce any directory or file created under workarea gets the group from workarea rather than user group.

2. Workarea group is changed after creting files and folders in the workarea. Is there any readymade way to set the files and folders in that with the workarea group other than writing a script to parse recursively and inherit permissions.

Thaks alot in adv.

Find more posts tagged with

Comments

nipper

You can use the submit.cfg to update the permissions once the file has been submitted to Staging. This should cover almost all of the pain points, with the exception of a new file prior to submit.

shameem

I believe the submit.cfg can only set the permissions as add-windows-permission on the folder/file, but the group set through inheritance will remain intact.

Couldn't find anything windows equivalent to stickybit on unix. Seems to be setting stickybit, default_workarea_permissions entry in iw.cfg all of them for non-windows. Windows Teamsite still no solution found. Keeping my hunting on till I get some expert inputs.

Rick Poulin

Your query doesn't really make sense to me. On Windows, there's no such thing as an 'owning group' -- there's only a list of ACLs. Also, all files/folders inherit ACLs by default, so your problem shouldn't exist unless you're creating files in a folder where this has been disabled.

shameem

Sorry, may be my terminology is wrong rpoulin, but every object (file/folder) under workarea has owner, group. permissions and inherited permissions.

As I mentioned

First issue is not having workarea group set on the object automatically. Where as this was resolved by sticky bit in unix environment.

Second issue is, if workarea group changes, not able to updated inherited permissions on objects inside workarea. Similar to security setting on windows folder and allowing to inherit permissions to subfolders/files.

Hoping that it clarifies my query.

nipper

shameem wrote:
I believe the submit.cfg can only set the permissions as add-windows-permission on the folder/file, but the group set through inheritance will remain intact.

You can be much more granular with the submit.cfg. You can set one folder to groupA, another to groupB, a different file type to groupC. So that can fix the permissions AFTER the file has been submitted.

Adam Stoller

You can also go through the UI to change permissions on the files / folders and (I believe inheritance) if you don't want to go through Windows Explorer or use cacls -- this will take care of already existing assets. The submit.cfg though is probably your best long-term solution going forward.

shameem

Thank you for all your valuable inputs. We have resolved the issue atlast with a script only, even though not willing to do so.

1. Wrote a script to set remove the old inherited permissions and inherit new permissions from the workarea.

iwaccess set-windows-inheritance <vpath(file/folder)> false (to remove existing)

iwaccess set-windows-inheritance <vpath(file/folder)> true (to set new)

2. As I couldn't find stickey bit alternative in windows environment, same script is used to update the group using iwchgrp.

thanks alot once again.

Rick Poulin

shameem wrote:
Sorry, may be my terminology is wrong rpoulin, but every object (file/folder) under workarea has owner, group. permissions and inherited permissions.

TeamSite can assign a group to a file/folder object, but this has no actual effects on a Windows platform because the OS doesn't recognize group ownership. Setting it doesn't change anything at all.

That said, the solution you just posted solves a longstanding bug in TeamSite that dates back to at least v6.5 -- changing the workarea ownership affects its ACL, but the change does not cascade. "Blinking" the inheritance property on objects at the root of the workarea fixes this, and there should be no need to "blink" recursively down the tree.

shameem

Its a kind of bug or functionality missing, you are right. I have gone through some posts Ghoti and you replied for this same issue in years back.

============

Blinking" the inheritance property on objects at the root of the workarea fixes this, and there should be no need to "blink" recursively down the tree.

=============

I am not sure you meant to say blinking at workarea will inherit, which is not happening so blinking at each object recursively becomes mandatory, whcih the commadnsI posted will resolve.

Rick Poulin

shameem wrote:
I am not sure you meant to say blinking at workarea will inherit, which is not happening so blinking at each object recursively becomes mandatory, whcih the commadnsI posted will resolve.

I said you need to blink on the immediate children objects of the workarea, so basically the folders at the root of the WA. If you blink those, there should be no need to blink subfolders or anything further down.

Vendim Birbili

We went through that exercise last year on 7.3.2 windows and we chose the submit.cfg.

To remove permission we used

C:\Interwoven\TeamSite\bin>icacls y:\default\main\component- guide\WORKAREA\shared\templatedata\Product\SimplePromo /remove:g testuser /t

To grant

C:\Interwoven\TeamSite\bin>icacls y:\default\main\component- guide\WORKAREA\shared\templatedata\Product\SimplePromo /grant testuser:F /t