Re: Get all issues with attached files

On Sun, Oct 05, 2014 at 09:26:15PM +0300, anatoly techtonik wrote:
> On Fri, Oct 3, 2014 at 4:19 PM, Ralf Schlatterbeck <[email protected]> wrote:
> > On Fri, Oct 03, 2014 at 03:45:17PM +0300, anatoly techtonik wrote:
> >> I am very skeptical about this use case. Can you describe the real
> >> attack or case you faced with?
> >
> > If a user has no 'View' on a property but can query all property she can
> > create a query that tells her the contents of the unknown property. This
> > works for string properties (because roundups string search is always a
> > substring search) as well as Link/Multilink.
...
> 
> Do you mean the query like "give me all users with empty password"
> will work even if I don't have view permission on password?
Yes, for example.

> Isn't it the job of a query builder to fail with permission error if
> an attempt is made to run a comparison over the data that user can not
> see?
Maybe, we can discuss this. So far the queries fail silently and don't
take the failing attribute into account when searching.

> Why leave permission open and search closed?
Search needs access to the label property and id attribute.
There is usually no explicit reason to have open permission and no
search but the list of attributes that are allowed but in our example
case permitting id on file and msg wasn't done.
Maybe it's a good idea to allow searching if only the label property is
allowed (and not require the id).

> > Yes, making permissions part of the schema is probably a good idea. This
> > decision dates back a *long* time.
> 
> Do you have an exact trace where this happened? Maybe there were some
> good reasons that were actual at that time? (I think that some informal blog
> post is a good idea for such things).
No, this was in the early days when I wasn't even contributing to
roundup :-)

> > There are several locations where query options are ignored silently,
> > e.g., malformed properties in a search (e.g. date).
> 
> Can we make error reporting optional? If user wants to ignore errors, let
> him do this.

I think currently our forms still lose some values when an error occurs
during submit. If we can get that fixed I think we should by default
raise an error (and, yes, maybe we want to allow ignoring errors when
the user fills out a search form).

> > Note that before the introduction of Search permissions the roundup
> > machinery already filtered the results it returned to you. So if you
> > were not allowed to see certain items these were filtered from the
> > search results shown. You can determine that your results are filtered
> > by the time the query takes, because filtering happens in python :-)
> 
> N-a-a-a-i-ce. =) Well, filtering results seems logical, but if you say that
> there is an attack to guess the actual value, then it doesn't work to
> conceal info.

If you don't have view permissions on a property but you allow all
searches the user can find out what the denied property contains, yes.
That's why search permissions were introduced.

> So, "I want to run queries that compare data" and "I want to hide data"
> are not really reachable at the same time. What is the case when you
> need both?

I currently don't have a use-case for this. I think the two requirements
are fundamentally incompatible, though.

> Why not just prevent running query over data that can not be viewed
> - why another 'search' permission - I don't get it?
Because sometimes you want to explicitly allow searching if you have,
say, a check function in your permission. In that case the values you
show are filtered after searching so this is 'good enough' for
implmentiing some permission schemes.

> >> As a consequence of this design decision now I need to do extra
> >> 5000 queries or even more in a row to b.p.o tracker to find all issues
> >> with files.
> >
> > Isn't it possible to fix the configuration so that your queries work?
> > But finding all issues *with* files is still not possible directly
> > because the negation ('-2' special id) and querying for unset values
> > ('-1') don't mix. This should be fixed ...
> 
> I don't have access to tracker and so far I fail to explain how it works and
> why I need view permission on file id. If I open
> http://bugs.python.org/file34276 the id is in URL. Ticket also has a link
> to this id.
As written above: It's probably a good idea to remove the requirement
for permission on id to allow searching.

> If file id is filtered from everythere, then why display query works?
> It is not secure in any way..
> 
> >>> pp (p.display ('issue9644', 'files'))
> {'files': ['18578']}
Yep. I think the id property can't be restricted from viewing.
Thats why it's probably a good idea to not require Read on ID for search
permission.

> Is it possible to implement "Allow, Deny" rule order? Meaning that every
> property is allowed to be accessed unless it is forbidden? In this case
> configuration will be much more sane as you can clearly see which fields
> are hidden and why.

No all properties currently are 'allow' only. I think this is a good
design, look through discussions how many people don't understand
Apache's model of allow/deny .-)

Ralf

-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   http://www.runtux.com
Reichergasse 131, A-3411 Weidling       email: [email protected]
allmenda.com member                     email: [email protected]

------------------------------------------------------------------------------
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk