mugle-dev team mailing list archive

[Matt Giuca <786876@xxxxxxxxxxxxxxxxxx>]

> I am wondering what happens if I simply remove that early check
> that throws the UserPrivilegeException, whether the privileges
> are still taken care of later on.

It seems that if you remove the early check, no exception is thrown; the
data just silently fails to be written. From a client perspective, this
means that it will say "it changed successfully", but if you refresh you
will see that the old data is still there.

So it isn't a good idea to remove those checks. That's a pity, because
they are duplicating the logic of the public/private system later on.

This is getting way too complicated for me, so I am just going to focus
on working around bug #786685 for now, and de-milestone this one.

** Changed in: mugle
    Milestone: 0.1 => None

** Changed in: mugle
   Importance: Critical => High

** Changed in: mugle
     Assignee: Matt Giuca (mgiuca) => (unassigned)

-- 
You received this bug notification because you are a member of MUGLE
Developers, which is a direct subscriber.
https://bugs.launchpad.net/bugs/786876

Title:
  Almost all data access is given private privileges

Status in Melbourne University Game-based Learning Environment:
  Triaged

Bug description:
  The data view system has been horribly abused. I haven't made a
  complete analysis of all the classes, but by the look of it, in most
  cases, objects are being presented with the private view whether the
  user owns it or not. Particularly the Game, GameVersion and GameFile
  exhibit this. The offending code is in the ServiceImpl classes, which
  assign the view type.

  At this point, most of our security is happening by accident, and can
  easily be subverted.

  It looks like most of the WRITES have buggy checks which end up
  resulting in "private" no matter what (eg, make it public if two keys
  of incompatible types are equal, but otherwise make it private). Most
  of the READS simply assign "private" without any checks at all. This
  code needs a complete audit.

  Note that you often don't notice these problems, because the role
  isn't high enough even for private access. For example, on GameData,
  most fields have public access for admin only, but private access for
  developers. That means guests can't see Games, but developers have
  full access to games - even ones they didn't create. This demonstrates
  the silliness of the developer role (bug #786842).

  This bug is responsible for bug #786685.