Exciting nemesis adventures in time and space

[Jeremy Morse]

Hi,

Over the last few months it's become apparent to me that some kind of
management facility needs to be present in the 'nemesis' software [0]. I
was previously not in favour of this idea, but it's necessary for people
in different areas to learn what a teams situation is. A specific
example is the chaps in Bristol not being sure how many teams would turn
up -- I can sort-of determine this by looking at account registrations,
which they couldn't see.

(I think in the past I thought we'd get a command line situation working
well, or something, but that hasn't happened).

Anyways, I began prototyping this recently by putting Michael and Danny
here in Bristol into school groups, both college- and team-, to give
them access to information about those schools, after confirming with
Peter that the schools wouldn't be able to do the reverse. The software
handled that just fine, with the occasional hiccup as you might expect.

Then, at the recent Kickstart I was approached by a competitor from CHB
who'd been granted teacher permission [1]. He pointed out that he was
capable of creating users in teams not at his school: on closer
inspection, he could create users as any team in the Bristol area, but
not outside.

By my recollection, this is down to one of the implementation details in
nemesis: to determine which teams are available in a /college/, nemesis
enumerates all members of the college, then enumerates all the teams
they're part of. When Michael and Danny became part of both those
colleges and /teams/, teachers could create accounts in all their teams too.

Clearly this is bad. I don't think there's any point in apportioning
blame: that solution for determining teams was a hack because in the
past we hadn't tied down the differences between teams and colleges, and
it's evolved further since then. It still isn't written down [2].

As a workaround, I've removed Michael/Danny from those teams, but not
the colleges, so have the same access but don't expand the set of
available teams to schools. However, they're still in four SR teams
team-SRZ{,2,3,4} which they need to actually develop things, and schools
will sill be able to create accounts with access to those teams.

An immediate fix would be to filter blueshirt accounts out of that
available-teams set building. A more long term fix is to actually encode
the relationship between colleges and teams into LDAP, eliminating the
need for these kinds of hacks. It'd look like this:
* Some memberUid's in groups would point at groups, not users. This
is fine under the current schema I believe (although we can dream
[3]).
* The userman tool and nemesis would have to change to account for
this fact
* There's the slight risk that other software would become confused
by this mixing.

An alternative would be to add a new segment in the LDAP tree
specifically for colleges, which only have teams as members. Then, only
software that has domain specific knowledge about what colleges are
would look at that segment. Nemesis for example would use that
information to map a teacher account back to a college, and then
forwards to a set of accounts.

The net fallout from this is:
* We owe the competitor who raised this some kind of hat
* One account from CGS ended up in team-GRD. From the IDE, they never
accessed any projects, and I've moved that account to the correct
groups.

[0] srobo.org/userman
[1] The teacher there appears to trust him with account registration stuff
[2] https://www.studentrobotics.org/trac/ticket/1447
[3] https://www.studentrobotics.org/trac/ticket/1053

--
Thanks,
Jeremy

[Peter Law]

Hi,

Jeremy wrote:
> *many, many things*

First some additional data points:

* The IDE uses team- groups to grant write access to teams' projects.
Arguably therefore mentors shouldn't be in teams other than the SRZ* ones.

* I've wondered at various times about making it so that team-leaders have
_no_ write access anywhere in the IDE. This was originally triggered by a
desire to avoid team-leaders writing code, but there hasn't been sufficient
need as yet to actually prevent that [A].

> Then, at the recent Kickstart I was approached by a competitor from CHB
> who'd been granted teacher permission [1].

My gut feel is that this should not be allowed. I'd be even more
uneasy if he is a minor (though again this is gut feel rather than any
actual evidence that it's not allowed). Of course IANAL so I'm not
sure if this is an actual legal problem.

As a team-leader he'll get different sets of emails than the
competitors, have access to their details (which is arguably something
which the actual team-leader is responsible for allowing, so I'd hope
we're not DPA liable for) and generally otherwise confuse things.

> He pointed out that he was
> capable of creating users in teams not at his school: on closer
> inspection, he could create users as any team in the Bristol area, but
> not outside.

> *analysis omitted for brevity*

This sounds like a straight bug. I believe your analysis is correct.

> An immediate fix would be to filter blueshirt accounts out of that
> available-teams set building.

Indeed, I can do this approximately immediately.

> A more long term fix is to actually encode
> the relationship between colleges and teams into LDAP, eliminating the
> need for these kinds of hacks.

Indeed, though as you noted elsewhere the relationship between the two
isn't yet defined [2]. As such I think that that *must* be solved
before we solidify it anywhere. Of course doing both at the same time
is a viable option (as each may help shape the other).

> The net fallout from this is:
> * We owe the competitor who raised this some kind of hat
> * One account from CGS ended up in team-GRD. From the IDE, they never
> accessed any projects, and I've moved that account to the correct
> groups.

As an additional note I've also removed my own user from the real team
I was in (which I was in for similar reasons).

Thanks,
Peter

[A] The original teachers who prompted this no longer do SR, I believe.

[Peter Law]

Hi,

Jeremy wrote:
>> An immediate fix would be to filter blueshirt accounts out of that
>> available-teams set building.

I wrote:
> Indeed, I can do this approximately immediately.

This is now done, in 90aadf6 [1]

Thanks,
Peter

[1] https://www.studentrobotics.org/cgit/nemesis.git/commit/?id=90aadf6