Tags:
create new tag
, view all tags
If I set an ALLOWTOPICVIEW on a page, should that also imply ALLOWTOPICCHANGE is set to the same list? Ditto setting DENYTOPICVIEW should imply DENYTOPICCHANGE?

That way if somebody forgets to set the CHANGE settings, but set the VIEW restrictions they are still "protected" from somebody simply changing the URL to an edit URL.

This would only take effect if the *CHANGE variables were not defined in the topic. From my quick look at the code, setting the DENYCHANGE variable to a non-existant group will not allow open edits for the topic, it would inherit the WEBDENYCHANGE settings. So we may need a pseudo group TWikiAllUsersGroup to allow anybody to edit the topic while restricting permission to view it. Personally I don't think allowing edit but denying read makes sense, but I would prefer to leave the option.

I wrote some code that has the following changes:

  • If the access type is CHANGE
    • gather the VIEW permissions as well
  • If there are no TOPIC*CHANGE permissions or WEB*CHANGE permissions, assign the view permissions as CHANGE permissions.

then pass through the code. Does this seem reasonable? I didn't implement the AllTwikiUsersGroup because I didn't have a need for it. But it could be added as a real topic to the main web and automatically added to by the register script.

Quips, comments, suggestions, evasions or answers? Exactly what should the semantics be?

-- JohnRouillard - 16 Aug 2002

  • "If I set an ALLOWTOPICVIEW on a page, should that also imply ALLOWTOPICCHANGE is set to the same list?"

IMHO, no -- I can easily imagine pages that I am willing to let others view but not edit.

  • "Ditto setting DENYTOPICVIEW should imply DENYTOPICCHANGE?"

    IMHO, this seems OK -- if I don't want someone to see something, I almost certainly don't want them to change it.

  • On the other hand (a question you did not ask) -- Maybe setting ALLOWTOPICCHANGE should imply that ALLOWTOPICVIEW at least contains everyone on the ALLOWTOPICCHANGE list.

I'm not sure any of this is really necessary though -- I don't set either very often (although that could change) -- I don't do it often enough to have any concern about trying to make it quicker or easier.

-- RandyKramer - 17 Aug 2002

RandyKramer, I think I didn't properly explain my idea. If I set ALLOWTOPICVIEW on a page, then only those people can view it. Nobody else is allowed to view it. However, anybody can still edit the page. Since you can view the page when you edit it, it makes the restriction somewhat less than useful.

My idea (which I didn't explain well) was to force the change restrictions to match the view restrictions if no change restrictions were defined.

If you have different groups of people who should be able to view and edit the topic, you can set both allowchange and allowview, my changes won't occur because you set at least one edit restriction. So you could set:

  • denyview = salesperson1
  • allowview = salesgroup, developmentgroup
  • allowchange = developmentgroup

and it would work as expected with only development being able to see the changes. marketinggroup would not be able to see the page since they aren't in allowview or allowchange. Also I think that salesperson1 would not be able to see the page. If the settings were only:

  • allowview = salesgroup, developmentgroup

then marketinggroup would be able to see the page by editing it directly by changing the URL. This was probably not what was intended.

If I set up the permissions as:

  • denyview = developerPerson1
  • allowview = salesgroup, developmentgroup
  • allowchange = developmentgroup

Then I have leakage in that developerPerson1 can view the page through the edit URL. However I am lothe to try to fix this because the user is alrady savy enough to restrict changes and should have properly set up his/her permissions. I am really concerned for the default case where people don't realise thay they need to set both CHANGE and VIEW restrictions in order to prevent viewing.

I hope I don't see too much of this either because it hinders collaboration, but I just had one of my managers ask me about restricting some documents from other groups notably sales. We don't want sales getting ideas that they try to sell before we have thought out the idea 8-). Setting the view restrictions would work for most of them, but security through obscurity isn't. Also a couple of our sales people were engineers and worked for our group beofre their promotion.

I think principle of least surprise requires an inheritance like this. We still have information leakage via document search that can be used to recreate the document, but if you don't have search context shown, it is more difficult to do.

Further comments?

-- JohnRouillard - 17 Aug 2002

Now I understand -- thanks for the explanation! I guess I didn't realize at first that there is a "security hole" in TWiki as you describe -- someone who is not allowed to view a topic can, if not restricted from editing it, call up that page to edit it via the URL and then (incidentally wink ) view it. IIUC, those "automatic" restrictions you are talking about would be explicitly included so they can be viewed and edited to refine them. In other words, if you define ALLOWTOPICVIEW but not ALLOWTOPICEDIT, when you save the page the contents of ALLOWTOPICVIEW is copied to ALLOWTOPICEDIT. So, the next time you edit, you could revise the contents of ALLOWTOPICEDIT to further restrict who can edit it.

-- RandyKramer - 19 Aug 2002

The code I built changed the logic in Access.pm to use the view restrictions if no edit restrictions were in force. It didn't actually create the ALLOW/DENY TOPICCHANGE keywords. It was easier to change the semantics in the core code (20 lines, including lines with just } ) rather than try to build a plugin to muck with page contents.

My opinion is that documentation of this inheritance is sufficient, I wouldn't expect people would need edit but not view access. I mean it could work if you blanked out their screen, but correcting errors may be a problem 8-). I don't think that most normal people would expect that somebody who can't view the topic could edit it.

If you needed dropbox style pages where people could create, but not edit or view, (thank [insert deity here] I don't deal with those environments amy more), a template that has the Set TOPICALLOWVIEW = AllowedUsersGroup already in the template should do. People deleting those lines would be shot.

Then you could aggregate the pages them using a BookView search, or % INCLUDE%. With a suitably descriptive name like: DropBoxEntry400103, the titles would give no help, but I am not sure about the WebIndex page. The summary would probably be a problem. At least the web would have to be taken off the "search all webs" action, and the WebIndex and WebSearch pages would have to be restriced viewing. Actually now that I think about it, any non-drop page in the web could be used to replace the WebIndex page and result in info leakage.

So the best alternative is just to not store truely confidental info on a TWiki site.

Well. I still think my patch is useful.

-- JohnRouillard - 19 Aug 2002

is this security hole still true? If so it should be addressed.

-- SvenDowideit - 15 May 2004

Security generally needs a bit of a re-think. While trying to work out the rules for WebDAV, I came across a few uncomfortable scenarios:

  1. No view does not imply no change or no rename
  2. No change does not imply no rename
  3. You can Set ALLOWTOPICVIEW = FictionalUser to deny everyone (including yourself) view access
  4. It is possible to rename a topic into a web where you are denied view, change and rename access
  5. It is easy to unwittingly deny yourself access. By the time you realise, it's too late.

Probably just the tip of the iceberg.

-- CrawfordCurrie - 15 May 2004

Updated progress fields with values from old manual "Nice to Have" table. Don't know how accurate they are.

-- SamHasler - 08 Sep 2004

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatdiff Access.pm.diff r1 manage 1.9 K 2002-08-19 - 22:16 JohnRouillard Diffs to prevent editing non-viewers
Edit | Attach | Watch | Print version | History: r12 < r11 < r10 < r9 < r8 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r12 - 2006-04-29 - SamHasler
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.