nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Workarea Security with TeamSite group

AXCHU

This would seem to be a popular branch/workarea question. I found two related posts on devnet with no answer, so I decided to consolidate them and hopefully someone who knows the answer or interwoven support can answer it.

My question is basically how to set directory security in workareas with os group and TeamSite group in 6.5/6.7.1.

Problem 1: with OS group permission, I can use submit.cfg to set directory permissions. However, although the user does not have 'read' access to a directory, it is still displayed as readonly in workarea view. Is there a way to hide the directory if the user does not have read access?

Problem 2: we are on Solaris 9. It is very nice to use TeamSite groups. However, Is there a way to set up file/directory security like submit.cfg does using TeamSite groups?

http://devnet.interwoven.com/forums_vb/showthread.php?t=22323&forumid=11&highlight=directory+workarea

http://devnet.interwoven.com/forums_vb/showthread.php?t=22672&forumid=11&highlight=directory+workarea

Find more posts tagged with

Comments

Adam Stoller

This would seem to be a popular branch/workarea question. I found two related posts on devnet with no answer, so I decided to consolidate them and hopefully someone who knows the answer or interwoven support can answer it.

My question is basically how to set directory security in workareas with os group and TeamSite group in 6.5/6.7.1.

Problem 1: with OS group permission, I can use submit.cfg to set directory permissions. However, although the user does not have 'read' access to a directory, it is still displayed as readonly in workarea view. Is there a way to hide the directory if the user does not have read access?

Problem 2: we are on Solaris 9. It is very nice to use TeamSite groups. However, Is there a way to set up file/directory security like submit.cfg does using TeamSite groups?

http://devnet.interwoven.com/forums_vb/showthread.php?t=22323&forumid=11&highlight=directory+workarea

http://devnet.interwoven.com/forums_vb/showthread.php?t=22672&forumid=11&highlight=directory+workarea

With respect to #1 you might be able to find a way to hide things by playing around with one of the CSS files used by the TS GUI (if readonly has it's own unique class) Otherwise, no - I don't believe there is any setting in TeamSite that will hide files or directories within a workarea, only settings to hide the branch and/or workareas if the user doesn't have permissions for them (and I believe you'd have to make sure they don't have "read" permissions too - i.e. drwxrwx--- or 770)

With respect to #2 - are you saying the submit.cfg doesn't work with TS Groups ?
I can't say I've tried it anytime recently - but I'm pretty sure I did with 6.5 SP1 or SP2 about 2 or 3 years ago - and I think it worked.

AXCHU

Thanks fish. Your comment is always helpful.

1. I've done a lot of testing and still cannot hide the files/dir that the users do not have access to. This presents an serious security issue when using 'List Modified', the user can potentially submit files that they don't have access to under cc-professional.

Hopefully, Interwoven will address this issue soon.

2. I figured it out. It was a misconfiguration on my part. It looks like it's working now.

sajiddc

Thanks fish. Your comment is always helpful.

1. I've done a lot of testing and still cannot hide the files/dir that the users do not have access to. This presents an serious security issue when using 'List Modified', the user can potentially submit files that they don't have access to under cc-professional.

Hopefully, Interwoven will address this issue soon.

Axchu,

Did you raise this issue with Interwoven Support? Is there a bug/FR for this?

Adam Stoller

Axchu,

Did you raise this issue with Interwoven Support? Is there a bug/FR for this?

It's not clear that this is a "bug" as opposed to a "feature request".

If the files are locked by someone else - and you have the correct setting in iw.cfg (can't remember it off the top of my head - you can look at the manual or the iw.cfg.example file) -- then TS won't let you submit those files.

If you don't have any access to the file or directory - you should not be able to read them, and I would think the workflow would not be able to access them to attach them to the job (unless the owner / creator of the workflow or the owner of the specific task does have such access)

Before you jump to the conclusion that this is a big security risk - please verify that it exists (after making sure that you set the access rights correctly at the OS level)

AXCHU

Yes, I have a ticket open with Interwoven on the issue #1. I will post what I find on this thread as soon as I have it.

I partially (hesitate**) agree with fish that this is likely a feature request than a bug fix unfortunately. I believe this is a result of directly using ACL for file/directory security which is a design fact. However, I (probably many other people) do wish that Interwoven have had/will implement a more sophisticated application security on top of ACL. The confusing point is that when users view modified files, they get a list of modified files from all folders even the ones they are not supposed to view; they have checkboxes in front of them to perform further actions; the securities can be further governed by workflow and custom triggers to ensure it doesn’t cause any harm; however, that’s still extra unneeded overhead for developer.

- axChu

CrosstabAlternatingRowHighlight.rptdesign

Adam Stoller

Yes, I have a ticket open with Interwoven on the issue #1. I will post what I find on this thread as soon as I have it.

I partially (hesitate**) agree with fish that this is likely a feature request than a bug fix unfortunately. I believe this is a result of directly using ACL for file/directory security which is a design fact. However, I (probably many other people) do wish that Interwoven have had/will implement a more sophisticated application security on top of ACL. The confusing point is that when users view modified files, they get a list of modified files from all folders even the ones they are not supposed to view; they have checkboxes in front of them to perform further actions; the securities can be further governed by workflow and custom triggers to ensure it doesn’t cause any harm; however, that’s still extra unneeded overhead for developer.

- axChu

How about training them to do View > My Modified Files?

13adam13

How about training them to do View > My Modified Files?

And then removing the View > All Modified Files, and putting it back for a specific group of people.