Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007217opensim[GRID] Grid Servicepublic2014-06-15 07:032014-06-15 16:31
ReporterFreakyTech 
Assigned To 
PrioritynormalSeverityminorReproducibilitysometimes
Statuspatch includedResolutionopen 
PlatformOSOS Version
Product Versionmaster (dev code) 
Target VersionFixed in Version 
Summary0007217: The sim can on occasions introduce faulty GridUser entries that prevent setting HomePositions correctly
DescriptionThe attached patch will remove the ability of the sim to introduce those entries.

However, on HG visitor Robust will add those HG UUI entries before the sim will do anything on GridUser service.

Therefore despite reducing the GridUser connector, the HG visitor difference will persist since Robust is mapping those entries to the longer HG UUI GridUser entry. The database modules actually look for the longest entry in the database.

On concern was originally that those HG UUI would not show up by that change. However, the foreignagent handler within Robust is actually preventing that by adding those GridUser entries early in the HG teleport.
Additional InformationThis mapping mechanism can now only be flawed by Robust initially. However, the GridUser handler should be limited to UUID only. This is not done within the attached patch.
TagsNo tags attached.
Git Revision or version number
Run Mode Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)
Physics EngineBasicPhysics
Script Engine
EnvironmentUnknown
Mono VersionNone
Viewer
Attached Filespatch file icon SimGridUser.patch [^] (2,313 bytes) 2014-06-15 07:03 [Show Content]

- Relationships

-  Notes
(0026261)
Diva (administrator)
2014-06-15 07:14

Thanks for trying!, but this patch cannot be applied as is, because it doesn't really address the kernel of the bug, it's just a band-aid. As band-aid, it has the potential to introduce more problems than the one it solves. GridUsers, by design, are identified by long UUIs, not just UUIDs. So if the UUI is wrong at the sim, something else is going on.

It would be great if you could improve your explanation of the problem.
(0026264)
FreakyTech (reporter)
2014-06-15 07:34
edited on: 2014-06-15 07:39

I could actually make a sim believe that your UUID belongs to the following:

92512718-03de-4827-a7bc-9f7a5e0c28ac;http://an.example.org/;Diva [^] Canto

All it is required to sent it to the GridUser service as a SetHome method.
It will store that and keep it that way unless an administrator deletes it.

Actually, did you ever look up how Robust handles the GridUser UUID only entry?. It expands it to the longest UUI entry it finds.

This is created from more trustworthy data that is provided through the teleport protocol.

In fact, by having untrusted data being directly passed to the database. you can just make any HG UUI entry go straight into the database.

It is sufficient that a configuration fault on some user's sim installation has happened.


Faulty HG UUI entries can be introduced by the following:
* Asset Serialization containing wrong Creator IDs
* Friend list entries
* Configuration faults

(0026265)
Diva (administrator)
2014-06-15 07:44
edited on: 2014-06-15 07:44

I wrote this entire thing, so I remember (vaguely) how it works :-)

There is a fair amount of trust that is assumed to exist between simulators and the central grid services, since these services are meant to serve the simulators. So if a simulator wants to put fake data in the database, by all means, go ahead. If your grid is like OSGrid, all bets are off -- starting with simulators being able to delete people's inventories.

So, again, this is not a good way of solving the bug.

(0026266)
danbanner (manager)
2014-06-15 07:57

Perhaps there is a solution that allows robust to refuse HG UUI for local users?
(0026267)
AliciaRaven (manager)
2014-06-15 08:04

Diva, the security issues you mention is that only for open grids or can a HG grid "inject" false information to another grid service?
(0026268)
Diva (administrator)
2014-06-15 08:14

Assuming port 8003 is either firewalled or using the HTTP authentication code that I recently added, then this does not happen in "normal" grids. But open grids like OSgrid cannot put those security measures in place -- they can't firewall 8003 and HTTP auth is mute, since they would have to make the password public.
(0026269)
Diva (administrator)
2014-06-15 08:15

@danbanner, yes, that's more like it.
(0026270)
FreakyTech (reporter)
2014-06-15 09:08
edited on: 2014-06-15 09:10

That is all it is about. Data from outside can never be considered immediately trustworthy. This should be common knowledge of all people doing network protocol design.

Validate that data whether it is actually allowed in that way.

Robust can validate at least the following things there:
* HG UUI for local user -> Adjust to local UUID
* UUID only for HG visitor (no local account) -> Adjust when existing HG UUI is there otherwise ignore

(0026271)
smxy (reporter)
2014-06-15 09:18

>* HG UUI for local user -> Adjust to local UUID

How can you tell if it's the local user or someone pretending to be them?
Would that undo blocking HG users by creating a local account with their UUID?
(0026272)
Diva (administrator)
2014-06-15 09:20

Simulators are not "outside", they are "inside" elements of a grid, they should be part of the same trust domain, and they MUST be trusted by the grid services, or else very little could be done. For example, deleting items from inventory would not be possible, or changing names of items, or reporting user's location on the grid, etc. The fact that this complete trust doesn't happen in OSGrid is a problem that injects much confusion into people running grids. OSGrid is an abnormality, a good one for testing in the large. But it should not be the norm for running opensim-based grids.

I'm going to write another note after this one that I will delete after a few minutes, because I don't want to give griefers ammunition.
(0026274)
FreakyTech (reporter)
2014-06-15 09:26
edited on: 2014-06-15 09:34

But that HTTP authentication and firewalling only protect against outsiders, a sim itself still can be source of broken entries with valid credentials.

I never talked about trying to get it dongled. It only means verify verifiable topics within network protocols. Therefore, in an open grid you can at least verify the obviously wrong data like HG UUI for a local user on GridUser.

(0026275)
Diva (administrator)
2014-06-15 09:40

@FreakyTech: yes. That's why I said that if the UUI is wrong at the sim there's something else going on -- a deeper bug -- that should be identified and addressed.

Doing a check for local user UUIDs at the service, like danbanner suggested, is a valid band-aid, but it would be nice to understand why the sim has the wrong UUI in the first place.

And now I'm going to delete my other note.
(0026276)
FreakyTech (reporter)
2014-06-15 09:43
edited on: 2014-06-15 09:44

It is not just a bug from these days. The data comes from assets and friendlist entries that contain broken UUI entries and are stored within asset server within asset serialization as CreatorID and entries within user's friend list for HG visitors.

So the generating issue can have happened years ago by configuration issues of some simulator instances or even grid configuration.

(0026277)
Diva (administrator)
2014-06-15 09:47

OK.
Do you want to give it a shot at fixing the GridUserService, so that you get familiar with the central services?
(0026278)
FreakyTech (reporter)
2014-06-15 09:49
edited on: 2014-06-15 09:57

I already took my path through central services: http://www.github.com/ft-/phpGridServer [^]

(0026279)
Diva (administrator)
2014-06-15 09:56

cool! Are you interested in doing it for core too, or not interested?
(0026280)
FreakyTech (reporter)
2014-06-15 09:59

your fellow opensim dev members gave me problem called CLA which I cannot sign without legal consultation first.
(0026281)
Diva (administrator)
2014-06-15 11:00

I'll look into this issue after the release, if it's still happening. It will be on the GridUser service side of things, since as far as I can tell, the simulators are already doing the best they can at detecting local grid users' UUIDs before contacting the service. I don't quite understand how wrong UUIs happen at the sim at this point, even with broken data coming from friends list and CreatorID.
(0026282)
FreakyTech (reporter)
2014-06-15 14:09

I implemented in phpGridServer the following ruleset:

UUID only with account => Pass
UUID only without account => Fail
HG UUI referring to local account => use UUID of that only
HG UUI referring to foreign account => use UUI
(0026283)
FreakyTech (reporter)
2014-06-15 14:24

btw this also means that in OpenSim.Region.CoreModules.World.Land.LandManagementModule the call to GridUserService.SetHome is done wrong. It does not map to UUI there.
(0026284)
Diva (administrator)
2014-06-15 14:49

Yes, now I remember. When I was doing this, I came to the conclusion that it didn't make sense for HG users to set home in a foreign grid, because they will not be teleported there when they hit Ctl+Shift+H. It looks like the check didn't make it to that code -- possibly because I was waiting for someone to convince me otherwise.

So convince me one way or the other.
(0026285)
FreakyTech (reporter)
2014-06-15 14:59
edited on: 2014-06-15 15:03

Would not work altogether since the foreigner's grid does not have access to that data. Neither does the sim store it in the foreigner's grid.

(0026286)
Diva (administrator)
2014-06-15 16:31

[16:29] <cia-opensim> Behavior change: only local users can set home in any parcel of a grid. Setting it for foreign users does not make sense, since cntrl+shift+H always teleports them back to their original grid.

(This is tangential to the reported issue)

- Issue History
Date Modified Username Field Change
2014-06-15 07:03 FreakyTech New Issue
2014-06-15 07:03 FreakyTech File Added: SimGridUser.patch
2014-06-15 07:03 FreakyTech Status new => patch included
2014-06-15 07:04 FreakyTech Description Updated View Revisions
2014-06-15 07:06 FreakyTech Description Updated View Revisions
2014-06-15 07:14 Diva Note Added: 0026261
2014-06-15 07:34 FreakyTech Note Added: 0026264
2014-06-15 07:35 FreakyTech Note Edited: 0026264 View Revisions
2014-06-15 07:39 FreakyTech Note Edited: 0026264 View Revisions
2014-06-15 07:39 FreakyTech Note Edited: 0026264 View Revisions
2014-06-15 07:44 Diva Note Added: 0026265
2014-06-15 07:44 Diva Note Edited: 0026265 View Revisions
2014-06-15 07:57 danbanner Note Added: 0026266
2014-06-15 08:04 AliciaRaven Note Added: 0026267
2014-06-15 08:14 Diva Note Added: 0026268
2014-06-15 08:15 Diva Note Added: 0026269
2014-06-15 09:08 FreakyTech Note Added: 0026270
2014-06-15 09:10 FreakyTech Note Edited: 0026270 View Revisions
2014-06-15 09:18 smxy Note Added: 0026271
2014-06-15 09:20 Diva Note Added: 0026272
2014-06-15 09:22 Diva Note Added: 0026273
2014-06-15 09:26 FreakyTech Note Added: 0026274
2014-06-15 09:33 FreakyTech Note Edited: 0026274 View Revisions
2014-06-15 09:34 FreakyTech Note Edited: 0026274 View Revisions
2014-06-15 09:40 Diva Note Added: 0026275
2014-06-15 09:40 Diva Note Deleted: 0026273
2014-06-15 09:43 FreakyTech Note Added: 0026276
2014-06-15 09:44 FreakyTech Note Edited: 0026276 View Revisions
2014-06-15 09:47 Diva Note Added: 0026277
2014-06-15 09:49 FreakyTech Note Added: 0026278
2014-06-15 09:49 FreakyTech Note Edited: 0026278 View Revisions
2014-06-15 09:56 Diva Note Added: 0026279
2014-06-15 09:57 FreakyTech Note Edited: 0026278 View Revisions
2014-06-15 09:59 FreakyTech Note Added: 0026280
2014-06-15 11:00 Diva Note Added: 0026281
2014-06-15 14:09 FreakyTech Note Added: 0026282
2014-06-15 14:24 FreakyTech Note Added: 0026283
2014-06-15 14:49 Diva Note Added: 0026284
2014-06-15 14:59 FreakyTech Note Added: 0026285
2014-06-15 15:01 FreakyTech Note Edited: 0026285 View Revisions
2014-06-15 15:03 FreakyTech Note Edited: 0026285 View Revisions
2014-06-15 16:31 Diva Note Added: 0026286


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker