Re: Get all issues with attached files

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. I have this problem when
you're using roundup for tracking e.g. working time of users, there you
have more privacy concerns, see my Time-tracking project
http://sourceforge.net/projects/timetracktool/
It doesn't have releases, just a git repo.

> I don't like "security by obscurity" design in open source security. It
> complicates code, wastes people time and just postpones the bomb
> effect. From my current point the limitation on search is a clear wart
> in Roundup design - both the approach (permissions are not part of
> schema) and implementation (errors pass silently, non optional
> feature).

Yes, making permissions part of the schema is probably a good idea. This
decision dates back a *long* time.
There are several locations where query options are ignored silently,
e.g., malformed properties in a search (e.g. date).

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 :-)

> 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 can understand the performance reasons. In this case it is still
> necessary to give message to users, so people can solve the problem
> in a different way - add caching etc. Silently crippling the tracker to
> prevent search overhead looks hackish (bad).

Yes I think that in the case of failing queries the user should be given
more feedback. It wouldn't solve your immediate problem, though.

> > The default for Search permission is View permission -- but only if the
> > View permission is not tied to a check-function. My guess is that there
> > is a check-function on issue.files in the python bug-tracker so the
> > default search permission doesn't apply.
> 
> All this stuff needs to documented and/or referenced from XML-RPC
> page. =/  I am a little upset with implicit complexity, because I've spent
> much more time than I expected. If not this list, how can I know about
> all that stuff to troubleshoot it properly?

This is a generic property not just of the xmlrpc interface. If you're
searching via a query url you are bound by the same restrictions.

> I don't see any differences between messages and nosy permissions:
> https://hg.python.org/tracker/python-dev/file/9bab717d18a0/schema.py

msg and file don't include the 'id' property while 'user' does.
Line 333 for the user perms, line 236 for file and msg permissions.

> > To add search permissions for a property you would add something like the
> > following:
> >
> > p = db.security.addPermission \
> >     ( name       = 'Search'
> >     , klass      = 'issue'
> >     , properties = ('files', 'messages')
> >     )
> > db.security.addPermissionToRole ('User', p)
> 
> Another thing in Roundup that needs refactoring. If only I had the time.. =)
Yep.
Reading this above it's probably easiest to grant the 'User' role read
access to msg.id and file.id.  Otherwise you'd probable need to add
Search permissions on file and msg, too.

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]

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk