Item1879: "Rename" does not care about access rights

If an unprivileged user (as I am) tries to rename Main.WebHome with the function "more topic actions/ Rename/move topic... scans links in all public webs...", one can see a lot of backlinks from Legacy.Topicname - I does not have any access to this web, I even didn't know that this web exists. This function breaks the security of a protected web and raises expectations for the users...

See also Item1793 - but not to show the summary is not enough for the security of the protected webs. If there is a topic named "!ReductionOfUnneededPersonal"...

-- WolfgangRaus

This website still runs 1.0.0

Have to verified that this is also the case in 1.0.6? You have clicked the 1.0.5 version in the form.

Raising to urgent

-- KennethLavrsen - 05 Aug 2009

With 1.0.5 the same, 1.0.6 I will test tomorrow or Monday...

-- WolfgangRaus - 06 Aug 2009

I cannot test this at work with 1.0.6 (see Tasks.Item1685) - will test at home.

-- WolfgangRaus - 06 Aug 2009

Tested with Foswiki-1.0.6, Sun, 21 Jun 2009, build 4272 (Debian 1.0.6-2 on Ubuntu 8.10): verified. The effect is exactly the same.

-- WolfgangRaus - 06 Aug 2009

Tested with Foswiki-1.0.6, Sun, 21 Jun 2009, build 4272 (updated from 1.0.5 on RHEL 5): verified.

-- WolfgangRaus - 07 Aug 2009

I can't reproduce this, so need more details. Specifically:

1. Regarding the 'secret' web. How is it protected? ALLOWWEBVIEW? NOSEARCHALL?
2. Regarding the user doing the rename. Are they denied read access to the 'secret' web in the normal UI? What happens when you type ..../Legacy/WebPreferences in the URL bar?

-- CrawfordCurrie - 08 Aug 2009

The protected web is secured with:

at home (Foswiki-1.0.6, Sun, 21 Jun 2009, build 4272 (Debian 1.0.6-2 on Ubuntu 8.10))
Set SITEMAPLIST = 
Set NOSEARCHALL = on
Set ALLOWWEBVIEW = Main.WolfgangRaus
Set ALLOWWEBCHANGE = Main.WolfgangRaus
Set ALLOWWEBRENAME = Main.WolfgangRaus 

at work (Foswiki-1.0.6, Sun, 21 Jun 2009, build 4272 (updated from 1.0.5 on RHEL 5))
Set SITEMAPLIST = 
Set NOSEARCHALL = 
Set ALLOWWEBVIEW = EDVReferatGroup
Set DENYWEBCHANGE =
Set ALLOWWEBCHANGE = EDVReferatGroup
Set DENYWEBRENAME =
Set ALLOWWEBRENAME = EDVReferatGroup 

at foswiki.org I do not know how Legacy is protected, but the effect typing the URL is:

• screenshot of trying to view Legacy/WebPreferences:
  

The same (but translated in german) I got at my installations. (Stop, not at work - there the error is caught by the application webportal, but the effect is the same: "this page is not released for public view....")

-- WolfgangRaus - 08 Aug 2009

In addition: I wondered why at work and at foswiki.org there exists so much amounts of found topics with references to Main.WebHome. For my testcase at home I had to insert a link explicitely to get the effect. The solution to this questions is: At work, I have our configuration protocol in the protected web (with links to Main.WebHome), and in two subwebs old data from our test installations - there nothing links to Main.WebHome, but the topic parents are - what? - Main.WebHome, cause this topics were moved from a web (folder) Main to the subwebs. At foswiki.org, I assume this is the same.

-- WolfgangRaus - 08 Aug 2009

So if I am right.

• The access rights are respected if you try to do the rename. If you rename a topic - and you do not have change rights to topics that link to the topic you try to rename you still see their name and their summary.
• If you try to go through with the rename - the topics you do not have change access to will not be renamed.

Is this correct?

We have a user interface problem here. I recognise the idea that webs you do not have read access to should be hidden to you also in the rename feature.

But what is the right behavior? If someone renames a topic - and they do not know that a hidden web has links pointing to this topic - they will break a lot of linking without even knowing what they are doing. They will not even be warned that they are about to do something that can have an impact. They do not even know they have to contact an admin that could do the renaming for them.

Not sure what is the best way to tackle this. But for sure the change of links on topics you have no write access to MUST be blocked. Otherwise we have a really severe security issue. Can you confirm this Wolfgang?

-- KennethLavrsen - 09 Aug 2009

At the step of a real renaming, the access rights in the protected web are respected - and you got no error message. The topics in the protected web are not updated.

The security bug is that you can see them without view access. The intention behind is clear - one should be given the chance to correct the links... but...

I am a little burnt out by this bugreporting at all. When I had a rest, I will outline my ideas to rename, move and delete for discussion. To select the right behaviour is a fiddly task

-- WolfgangRaus - 09 Aug 2009

Wolfgang, a tip for easier bug reporting; try to reduce to the configuration that has the least number of differences from a standard, "out of the box" configuration, and don't waste time testing the same thing against other almost identical configurations. Describe the configuration as clearly and simply as you can, what you did to cause the problem, and what you saw that you believe is not correct. Also, please don't report more than one problem per Task.

I'm still not 100% sure what is being reported here. Is Kenneth's analysis correct? AFAIK rename hides webs that you don't have CHANGE access to - there's a unit test that confirms this - but does not check VIEW access when reporting referring topics. Are you reporting that topics that you have change access to, but don't have view access to, are being listed in the referring topics list? You refer several times to "the access rights" but we have to know whether you mean VIEW or CHANGE, or both, in each specific circumstance.

-- CrawfordCurrie - 10 Aug 2009

Crawford, I tested this effect with other configs not till then I was asked to do so. (My other bug reports are a bit cumulative, I will improve this )

Reported is here: If one does not have view access to a specific web, one sees the topic names and (still, but not for long as I read in Item1793 ) the summary - means: parts of the content - of this topics if this topics are found at the backlinks check of the rename function. This is a security leak for the ALLOWTOPICVIEW access restriction.

This effect could happen very easy if topics were moved from a Web "Main" to a protected web in the filesystem, cause of the standard META.parent value "!WebHome". Of course only if one tries to rename Main.WebHome. In normal life, it will happen very infrequent and will depend on the amount of links leading from a protected web to unprotected topics and the frequency of renames of this topics. But the security leak is there.

Thanks for your patience.

-- WolfgangRaus - 10 Aug 2009

OK, that is starting to make sense then. As I said, the code checks CHANGE access but not VIEW access. So if you have a web where VIEW is denied but CHANGE is permitted then you will see this effect. I'll check the unit tests to confirm that this is the case.

-- CrawfordCurrie - 10 Aug 2009

No, you can see this effect if VIEW and CHANGE and RENAME is denied also. The info is displayed.

-- WolfgangRaus - 10 Aug 2009

RENAME is irrelevant, it only applies to the topic being renamed, not a topic referring to the topic being renamed. Topics that do not have CHANGE but do have VIEW should be listed. Topics that do not have VIEW should not be listed - and that's the bug.

I noticed while testing that subwebs are not searched for references; also a bug.

Fixed for 1.1.0

-- CrawfordCurrie - 10 Aug 2009

Curious, my examples at work are in subwebs. Anyway, thanks!

-- WolfgangRaus - 10 Aug 2009

You are testing on 1.0.6; I am testing on 1.1.0. Hence the difference.

-- CrawfordCurrie - 10 Aug 2009