Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006667opensim[GRID] Hypergridpublic2013-06-08 11:012015-02-28 12:09
Assigned To 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0006667: when accepting a friend request over hypergrid, this friend can edit my objects.
when accepting a friend request over hypergrid, this friend can edit my objects.
Steps To Reproduceusing opensimulator 0.7.5-post-fixes
using osgrid lbsa plaza

local user uuid = 39468680-5d8e-45b3-b21f-cd4133226d4b
osgrid user uuid = 855f0b91-d3f1-41bb-a051-251b054491a0

step 1:
my osgrid avatar is coming to our grid using hg tp
my osgrid avatar is asking the local user to be a friend
the friendship is accepted

Database status :
offline messages :
the local offline messages table is empty for both uuids

Friends table :
PrincipalID = 39468680-5d8e-45b3-b21f-cd4133226d4b
Friend = 855f0b91-d3f1-41bb-a051-251b054491a0;;ssm2017 [^] Binder;01d09ff1
Flags = 1

PrincipalID = 855f0b91-d3f1-41bb-a051-251b054491a0
Friend = 39468680-5d8e-45b3-b21f-cd4133226d4b
Flags = 1

step 2:
my osgrid avatar is going back to lbsa plaza
when arriving, the avatar is receiving an offline message notification
asking him to confirm the friendship while he was away.
my osgrid avatar is accepting the request

step 3:
my osgrid avatar is going back to our grid
my osgrid avatar is receiving 2 messages :
1 telling that the local user has given him the permissions to edit their
1 message asking him if he wants to be friend with local user
my local user is creating a primitive
my osgrid user can edit this primitive
database status : no change

step 4:
my local user is giving permissions to edit objects to osgrid user (using
the viewer)
database change : the flags are changing to 5 on the first entry

step 5:
my local user is removing permission to edit objects to osgrid user (using
the viewer)
database change : the flags went back to 1
the osgrid user can not edit object anymore

step 6:
my osgrid user is going back to osgrid
my osgrid user is coming back to local grid using hg tp
my osgrid user is reveiving again the 2 messages :
1 telling that the local user has given him the permissions to edit their
1 message asking him if he wants to be friend with local user
TagsNo tags attached.
Git Revision or version number
Run Mode Grid (Multiple Regions per Sim)
Physics EngineBasicPhysics
Script Engine
EnvironmentMono / Linux64
Mono Version2.6
Viewerfirestorm 4.4.0
Attached Files

- Relationships

-  Notes
Diva (administrator)
2013-06-08 17:19

Followed the steps, but did not see the same result. Upon returning to the foreign grid again, there were no further messages regarding friendships.
danbanner (manager)
2013-06-08 17:59

an HG user from another grid friended me and said they saw the same thing when they came to osgrid. I looked at *my* friends in the database and did not see anything to indicate they are allowed to edit my objects and apparently when they tried, said they could not edit my things.
hack13 (reporter)
2013-07-28 19:15

I have seen this issue before, do you happen to have RLVa enabled?
ssm2017 (reporter)
2014-12-06 07:20

sorry for the delay.
the issue is still here using OpenSimulator
the issue is grid wide (no rlva enabled)
justincc (administrator)
2015-01-07 16:16

I'm a little confused. In Step 4, is that done voluntarily by the local user or is that an involuntary change?

Assuming that we're talking about an involuntary grant, I wasn't able to reproduce this as of master 502aa7b. I teleported a local avatar to a foreign grid, made a friend with a foreigner on that grid and then teleported home to accept the "Please confirm this friendship" message. All subsequent reteleports or relogins of both avatars didn't see any object editing grants, or indeed any repeated friendship messages.

There could be something complicated going on here. What offline message module are you using?

This might have been fixed somehow in master code though I somewhat doubt it. If at all possible, please could you test with this.

In OpenSimulator with Hypergrid, the FriendsModule and HGFriendsModule handle friends management. I would expect HGFriendsModule.StoreFriendships() to be the critical section when a friend is added though this whole section of code is complicated, especially if requests are being stored offline.

On reviewing the code, there is no obvious place where the FriendsRights.CanModifyObjects value (hardcoded to 4) could be set automatically, so maybe that is being generated as a subsequent grant. But there's no sign of this either.

I have started making some notes on the code and message exchange at [1] but this will be a long process.

Are you able to provide logs when this happens? We would need logs of both regions (one where friendship is made, one where confirmation is accepted) and logs of the robust instances of both the home and foreign grid.

[1] [^]
Gavin Hird (reporter)
2015-01-08 00:08

What viewer was used when this was originally reported?

Could it be bad interaction with a viewer – I have seen different results depending on the viewer used. On SecondLife behavior is reasonably consistent between viewers, on opensim less so for many functions.
justincc (administrator)
2015-01-08 15:08

If it was a viewer it would have to be issuing the 'edit my objects' permission by itself for some reason, which seems unlikely.

To be honest, I suspect some bad interaction with the offline IM code though the builtin offline IM doesn't have any obvious problems.
ssm2017 (reporter)
2015-01-10 02:40
edited on: 2015-01-10 02:47

i have some news about this issue and maybe this is solved (need to see with time).
to answer previous questions :
the step 4 (force edit objects) was done manually to override the db value.
there was no issue in the region or robust logs.
nothing is stored in the offline im db concerning the 2 friends.
issue was seen in firefox and also in singularity.

what i have done on yesterday :
i have compared the Friends table scheme with a working grid and could see 2 things weird :
1/ the db engine was MyIsam instead of InnoDB
2/ the PrincipalID was a char(36) instead of varchar(255)
i have tried to update the table but it was refused because there were a lot of duplicates so i have created a new table, exported the old one and then edited by hand the sql file to try to remove every duplicate entry and then filled the table again.

old table :
    CREATE TABLE `Friends` (
      `PrincipalID` char(36) NOT NULL DEFAULT '00000000-0000-0000-0000-000000000000',
      `Friend` varchar(255) NOT NULL,
      `Flags` varchar(16) NOT NULL DEFAULT '0',
      `Offered` varchar(32) NOT NULL DEFAULT '0',
      PRIMARY KEY (`PrincipalID`,`Friend`),
      KEY `PrincipalID` (`PrincipalID`)

new table :
CREATE TABLE `Friends` (
  `PrincipalID` VARCHAR(255) NOT NULL DEFAULT '00000000-0000-0000-0000-000000000000',
  `Friend` VARCHAR(255) NOT NULL,
  `Offered` VARCHAR(32) NOT NULL DEFAULT '0',
  PRIMARY KEY (`PrincipalID`(36),`Friend`(36)),
  KEY `PrincipalID` (`PrincipalID`)

Expectations :
the table was using myisam and i had an issue trying to update it so maybe during a robust update, the migration step was not able to update the table too or there is a missing update in the robust migration scripts (the step to update the PrincipalID field from char(36) to varchar(255).
i dont know why the table was using myisam engine (maybe an old opensimulator format or a change we have done few years ago manually)

actual status :
i have tested with a known working grid and i do not have the issue anymore after updating our db.

Gavin Hird (reporter)
2015-01-10 02:50

PrincipalID shall be char(36) as it holds a UUID and only that which is per definition 36 chars. It shall also be unique.

In the new table you have PRIMARY KEY (`PrincipalID`(36) which is going to give you trouble since you have defined PrincipalID` VARCHAR(255)

> i have tried to update the table but it was refused because there were a lot of duplicates so i have created a new table

The duplicates are probably the root cause of your issues, and I would advice you to use the official table definition, but repopulate it with the de-duplicated data.
zadark (reporter)
2015-01-10 03:04

Friends table PrincipleID is unusual in that for a HG friend the field is extended as their home uri is appended to the UUID
xxxxxxxx-7e6d-45a3-9677-7ebc12b78e7d;;their [^] name;xxxxxxxx
ssm2017 (reporter)
2015-01-10 03:09

the new robust installations are using a varchar(255) in the Friends table for PrincipalID and Friends columns to be able to store hypergrid friend in the format :
uuid;hg loginuri;hg user name;some chars that i do not know

i think that the primary key is using 36 because it is checking the first 36 chars instead of the full field value.
maybe im wrong but this is what i could see on a recent known working grid installation.

i have just seen the migration script in :
line 28 thru 30
that is confirming that
Gavin Hird (reporter)
2015-01-10 03:17

OK, I see what's happening here

There are actually pairs of records for each friendship. I did not realize that so MY BAD.

For friending myself on Kitely as an example from xmir there are two set of records.

One holds the string with the UUID;HG address;Name; xxxxxxxx in the PrincipalID field, and the other the same information in the Friend field.

In this case it makes sense to have the PRIMARY Key only include the first 36 chars of PrimaryID

- Issue History
Date Modified Username Field Change
2013-06-08 11:01 ssm2017 New Issue
2013-06-08 17:19 Diva Note Added: 0024047
2013-06-08 17:59 danbanner Note Added: 0024048
2013-07-28 19:15 hack13 Note Added: 0024227
2014-12-06 07:20 ssm2017 Note Added: 0027075
2015-01-07 16:16 justincc Note Added: 0027172
2015-01-08 00:08 Gavin Hird Note Added: 0027173
2015-01-08 15:08 justincc Note Added: 0027183
2015-01-10 02:40 ssm2017 Note Added: 0027196
2015-01-10 02:47 ssm2017 Note Edited: 0027196 View Revisions
2015-01-10 02:50 Gavin Hird Note Added: 0027197
2015-01-10 03:04 zadark Note Added: 0027198
2015-01-10 03:09 ssm2017 Note Added: 0027199
2015-01-10 03:17 Gavin Hird Note Added: 0027200

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker