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; } } }

suggestions for confidentiality

nico

I'm about to work on a board of directors site and there are sensitive documents and pdfs I should not have access to view. Given that I am a teamsite master and sys admin of the box how can I go about ensuring that I cannot open/view those files? Teamsite 552 win2k

Thanks,
Nico

Find more posts tagged with

Comments

Johnny

ACL's within the workarea.

Setting the ACLs within submit.cfg is the way.
Just set the area with a group that you guys dont belong to.

John Cuiuli

Migrateduser

What I've done in analogous cases was make PGP available for client-side use. Then documents could be published with any readership desired, either to individuals, or to shared addresses.

Maninder_IBM

Set up a secure content area. Apply permissions to the directories with groups containing only those members that need permission. Published documents on the web can have similiar security.

In theory 552 supports secure authoring. (I am having a few probs at the moment though!)

gzevin

this is an old thread. Has anybody done anything like that?

I've set up the workarea to have 770 permissions ... This security works, but files could not be previewed.

any clues, I am trying to resolve myself, but will appreciate any thoughts

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

iwovGraduate

"Files could not be previewed" -- even by the user who owns (or is member of the group for which you have rwx on group) the file ?

Johnny

hmmm initial thoughts may be the iwui user (assuming solaris) , or more likely the user of the preview web server, can't read those files.

Maybe that could be added to those "secure" groups...

That's probably not the best solution because it pretty much defeats your secure setup
EG http://tsserver:81/iw-mount/......./secure.html

interesting

John Cuiuli

Migrateduser

Wouldn't restricting access from iwui (for example) have negative TS consequences? What if one of these files goes through workflow or has certain functions that requires user access to be performed on it?

Dave

Current Environment(s):
(1) TS 6.1 SP2 on W2K3
(2) TS 6.1 SP2 on W2K
(3) TS 6.1 on W2K

Johnny

I can only see a messy solution...

a proxy rewrite to a SUID CGI (iw_cgi_wrapper may not be enough on its own) that reads the file and sends it to the browser.

John Cuiuli

gzevin

yes, because the customer webserver needs that 'all users' 'r' bit set

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

gzevin

we'll try this

Enabling iwproxy Access Control

By default, iwproxy allows any authenticated TeamSite user to view any
file in TeamSite. To
configure iwproxy to verify the users' ability to read certain files
in the file system, add an
[iwproxy_access_control_enabled] section to your iw.cfg file based on
the example that
follows.

This example implements the following policy:

" All users should be able to read any document on the intranet,
except for files in the
/hr/ directory, which require specific read access.
" All users should be able to read any document on the internet site.
" For all other branches, iwproxy should check to ensure the current
user has read access.
[iwproxy_access_control_enabled]
_default=yes

_regex=^/iw-mount/dc/main/intranet/(((WORKAREA|EDITION)/[^/)]+)|STAGING)
/hr/=yes
_regex=^/iw-mount/dc/main/intranet/(((WORKAREA|EDITION)/[^/]+)|STAGING)/
=no
_regex=^/iw-mount/dc/main/www%20external/(((WORKAREA|EDITION)/[^/]+)|STA
GING)/=no

...

setting up branch and workarea security in iw.cfg does not work at all, all the users are still able to view all the branches

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU