An apparent security hole in roundup...

I've noticed that with the classic tracker's schema
concerning queries, any
user can edit any and all queries regardless of whether they
created it or
marked as private despite the following in schema.py:

# Users should be able to edit and view their own queries.
# They should also be able to view any marked as not
private.
# They should not be able to edit others' queries, even if
they're not private.
def view_query(db, userid, itemid):
    private_for = db.query.get(itemid, 'private_for')
    if not private_for: return True
    return userid == private_for
def edit_query(db, userid, itemid):
    return userid == db.query.get(itemid, 'creator')
p = db.security.addPermission(name='View', klass='query',
check=view_query,
description="User is allowed to view their own and
public queries")
db.security.addPermissionToRole('User', p)
p = db.security.addPermission(name='Edit', klass='query',
check=edit_query,
description="User is allowed to edit their
queries")
db.security.addPermissionToRole('User', p)
p = db.security.addPermission(name='Create', klass='query',
description="User
is allowed to create queries")
db.security.addPermissionToRole('User', p)

All it takes is to point the browser at the query class
instead of a particular
query. The generic template allows editing an entire class
if create permission
is granted on the class (which it must be in the case of
queries to allow users
to create their own queries).

How should I plug this apparent security hole?

Creating a new template that simply does not allow editing
the query class as a
whole is not enough as a template argument (or a
carefully hand built URL) can
be used to work around this.

Any ideas. Am I missing something?

Bruce

------------------------------------------------------------
-------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the
chance to share your
opinions on IT & business topics through brief
surveys-and earn cash
http://www.techsay.com/default.
php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Roundup-users mailing list
Roundup-userslists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/roundup-u
sers

On Thu, 12 Apr 2007, Bruce Tulloch wrote:
> I've noticed that with the classic tracker's schema
concerning queries, any
> user can edit any and all queries regardless of whether
they created it or
> marked as private despite the following in schema.py

What actually happens is that the search form loads up the
other person's 
query to edit but copies it when you save the query. You're
not editing the 
other person's query.


    Richard

------------------------------------------------------------
-------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
take
control of your XML. No limits. Just data. Click to get it
now.
http://sourcefor
ge.net/powerbar/db2/
_______________________________________________
Roundup-users mailing list
Roundup-userslists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/roundup-u
sers

Richard Jones wrote:
> On Thu, 12 Apr 2007, Bruce Tulloch wrote:
>> I've noticed that with the classic tracker's schema
concerning queries, any
>> user can edit any and all queries regardless of
whether they created it or
>> marked as private despite the following in
schema.py
> 
> What actually happens is that the search form loads up
the other person's 
> query to edit but copies it when you save the query.
You're not editing the 
> other person's query.

Thanks again Richard. I have since checked and what confused
me was that the
CSV editor (ie, the one that pops up by default if you don't
specify the edit
template when visiting the query class) appears to allow the
editing of any
query record.

It doesn't (any update is refused if one attempts to) but
all query records
(private or public) are visible to any user with view
permission on the query
class (which is of course everyone).

I think this may be another case where the modified call to
the check function
that I suggested in my other recent email:

Re: [Roundup-users] Permission does not call check unless
item	exists, why?

might be a good idea.

That is, I seek to disable view access on a class for some
users but allow them
create permission. However I cannot write a permission check
function to do
this right now because it is not called when there is no
item ID.

Is there another way to achieve this?

If not, I am prepared to take ownership of this proposed
change eventually but
I am not yet confident enough of my knowledge of all the
details of the roundup
core the modus operandi for its development to do this yet.
Soon though I hope.

Many thanks again for your helpful feedback.

Cheers, Bruce.

------------------------------------------------------------
-------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
take
control of your XML. No limits. Just data. Click to get it
now.
http://sourcefor
ge.net/powerbar/db2/
_______________________________________________
Roundup-users mailing list
Roundup-userslists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/roundup-u
sers