Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008120opensim[REGION] OpenSim Corepublic2017-01-16 18:062017-06-04 15:43
Reportermewtwo0641 
Assigned To 
PrioritynormalSeverityblockReproducibilityalways
StatusnewResolutionopen 
PlatformOSOS Version
Product Version0.9.0 
Target VersionFixed in Version 
Summary0008120: Various issues with serverside_object_permissions = false
DescriptionTesting on OS pre-release v0.9.0.0 RC2 on a brand new and clean database

When setting serverside_object_permissions = false there are a couple issues that arise that make inventory items that were created by another user broken to the point that they can't be used.

This is especially true of inventory items loaded from an IAR to another user but those items were not created by that user.

Effects that I have noticed so far of this issue are:

1. Items in object inventories show up no mod / no copy, sometimes no perms at all. OpenSim seems to be, in effect, completely ignoring the serverside_object_permissions = false setting. (This worked as expected in previous versions.)

2. Affected objects that are attachments can not be worn

3. When attempting to delete the affected item from user inventory the viewer gives the warning that says that there is a link to the item and that the link should be removed first. But there is no such link. This makes me suspect that OpenSim believes that these items exist in the inventory of either who ever created it, or who ever owned it last, even though they show up in the other user's inventory as a result of loading the IAR to that user. Support for this hypothesis is the fact that OpenSim believes that there is a link to it when there isn't and also when wearing scripted attachments the script tries to interact with the last person who owned the object instead of the person attempting to wear it. (I noticed that one of my AOs I tried to wear, while it would not attach, gave the last user who owned it the dialog asking for animation permissions.)

4. Going god mode and doing "Force Owner Permissive" does not seem to (fully) fix the effected items either; Although it appears to fix the no perms problem in object inventories; they still can't be worn.

The only way that I can tell to fix it is to leave serverside_object_permissions = true; But this is not how I desire to run my personal testing/"item creation" server. I prefer to not have to deal with permissions on my sandbox/non public server.
Steps To Reproduce1. Set serverside_object_permissions = false in OpenSim.ini

2. Load an IAR to a user with items created by another user.
   a. To fully test, it's helpful that these items contain scripts in them and possibly other assets.
   b. Should have some attachments; especially scripted attachments in the IAR

3. Rez an item on ground that contains assets in them.
   a. Some items in the object's inventory will probably show up no copy / no mod, sometimes no perms at all, regardless of the serverside_object_permissions = false setting
   
4. Try to wear one of the attachments
   a. If the item is affected then you won't be able to wear it at all
TagsNo tags attached.
Git Revision or version number
Run Mode Standalone (Multiple Regions)
Physics EngineubODE
Environment.NET / Windows64
Mono VersionNone
Viewer
Attached Files

- Relationships

-  Notes
(0031550)
UbitUmarov (administrator)
2017-01-17 00:47

serverside_object_permissions = false is a very questionable option that may be removed, unless OAR and IAR operations are also disabled
(0031551)
mewtwo0641 (reporter)
2017-01-17 03:46
edited on: 2017-01-17 03:47

I don't understand, how is it questionable? The option has been there for as long as I can remember and I can't see any harm in it being used for one's own personal and non public server, that they have complete access to console and database. To run services for public access would definitely be best practice to have permissions enabled for sure... But not every one runs a publicly accessible install. For instance I actually run two separate installs; one is WAN accessible, this one I keep serverside_object_permissions = true since other people access it. My other one is private and accessible only to myself, this one is my sandbox, test bed, scripting area, and my place where I do all my building. I keep serverside_object_permissions = false for this one so that it makes life a little bit easier for myself when I'm testing scripts between multiple avatars and keeping up with multiple "test inventories".

I am in no way meaning to be disrespectful or ungrateful. You guys do a lot of hard work and put in your time to make OpenSim a great thing and I am always speaking good of the project to my friends and recommending that they try it out... I just hate to see the project head to the direction of "You run it our way, or no way", that's all. OpenSim is supposed to be about choice and flexibility in how one wants to configure and run it is it not?

(0031552)
Mandarinka Tasty (reporter)
2017-01-17 03:53
edited on: 2017-01-17 12:12

Hello :)

I absolutely agree with You, mewtwo. It should work = everyone should decide by herself / himself to use permissions or not use them at all.

Probably Ubit did not understand you precisely.

I also observe all last changes that refer to permissions system and it looks there is much work to do, and everyone needs to be patient.

Ubit and Melanie have started to rebuilt all this system entirely, and the probability that something doesn't work properly or work in other way, than in the past, is not less.

So let's wait little bit. I hope :)

(0031553)
mewtwo0641 (reporter)
2017-01-17 04:01
edited on: 2017-01-17 04:03

@Mandarinka Right, I understand :) I am currently referring to the release candidate that was announced in the mailing list last week though I did test master too to see if anything had changed. I agree though that we should wait and see how the current permissions system update changes is playing out; I hope for the best though because this option is very useful in testing environment and sandbox environments.

(0031554)
UbitUmarov (administrator)
2017-01-17 04:05
edited on: 2017-01-17 12:11

it is questionable with OARs, IARs, HG and/or grid options active
and there are no checks about that.

"It should work = everyone should decide"
does not mean we will allow a obvious Steal_all_Objects = true option.

but at this point making the case TRUE working is the highest priority

(0031555)
Mandarinka Tasty (reporter)
2017-01-17 04:12
edited on: 2017-01-17 12:18

@Ubit )

If you start to say about so called "obvious Steal_all_Objects = true option" so you need to close OpenSim project, maybe ? or remove all aplications of databases ? or...

It is enough to use, even poor SQLite, to alter every and each permission with all names of all assets, creators etc etc.

So let's not put it in such way.

Persons should decide, that is not Linden Lab, that decides what is allowed or not.

Greetings )

(0031556)
UbitUmarov (administrator)
2017-01-17 04:14

what part of "obvious" don't you understand?
(0031557)
aiaustin (developer)
2017-01-17 12:05
edited on: 2017-01-17 13:51

All uses of OpenSim are not commercial grids, but may involve teams working together in educational and cooperative environments. We have often had issues of sharing what are meant to be full perm items even between a couple of avatars in a team. Sometimes internal items, textures, scripts or what not that were created by a different team member and meant to be provided full perm to a coordinator but that have permission transfer issues in some versions of OpenSim stop a simple export being allowed and that prevents transferred items coming over as full perm and able to be properly exported or packaged up for all to use when intended to be open access. The export bit has never seemed to work and is usually unset and greyed out even for the creator/owner for example.

I appreciate that the permissions system is in a state of flux with many new commits going in just now from @Ubit and @Melanie and hope those achieve the desired effect. But I worry when I see comments about "legacy" items permissions getting more restricted as a side effect. That would be VERY bad if its the final outcome in my view.

You warned us dev master was now unstable and some of the code changes areexperiments that are not in a fit state to use in production yet... please let us know in the commit description when dev master is stable again and will not mess up legacy items.

(0031558)
mewtwo0641 (reporter)
2017-01-17 12:37
edited on: 2017-01-17 12:52

@Ubit I don't think that the option should be looked at as a way to steal objects. My reasoning for this is because if you're running your own grid then you likely already have access to the console and the database as well. Meaning that you're responsible for what happens on your own setup. As for the possibility of open grids such as OSGrid and someone connecting their own with this option set to false and stealing items... is a possibility yes; but instead of removing the serverside_object_permissions option, why not add in a grid side option something to the effect of grid_connect_enforce_permissions = true ? If this option is set true then grid services will reject connection of anyone's OpenSim instance if they've opted to set serverside_object_permissions = false on theirs. It would solve the problem of people connecting to other grids, taking stuff to their own place, and then doing whatever they do from there to strip the permissions since they would not be able to connect their OpenSim instance to the grid in the first place. It would also make the private owners happy to have this option back too.

As aiaustin has mentioned, this option is useful in collaborative builds where having to set permissions on every single thing as the build progresses is an inconvenience and slows things down... Even more so when permissions are not working properly.

As a side note... Speaking of possible breaking of permissions especially for legacy objects; If you are working to remove ways to alter permissions from the people that have administrative console access how are we then to fix item permissions that bug out leaving the owner and creator of the item with a permanently perm broke item?

I understand that IP theft is a concern but there must be other ways to deal with that other than taking options away from the users that find them legitimately useful.

(0031559)
UbitUmarov (administrator)
2017-01-17 14:43

Permission are about IP protection, commercial grids or not.
A flow of contents across opensim systems/use cases (including forks) is a must, either using HG, sharing OARs, IARs, etc. But that does need to respect IP (within reason)
(by reason I mean for example that security is not a absolute, is depends on the value of the secured asset and its lifetime).

But permissions are also about content protection against accidents (or abuse), even in open IP context.
They should never be disabled. Exception powers like local Admins should be used to by pass them case by case on a controlled and intentional way.
This were the main reasons for my initial comment.

(and yes, some of you may already know me enough to understand that things like
"It should work = everyone should decide" are not on my book in opensim dev context. But this is me, not talking for the all team on this)

Making our code work in a acceptable way is another story ;)
We do depend on your help with ideas, testing and feedbacks (like this)

And yes master is still only for testing this. Still not for use on "normal" regions.
Not that its all broken, I just know that some permission checks are still wrong (and with bad luck can damage a item)
(0031561)
watcher64 (reporter)
2017-01-17 15:19
edited on: 2017-01-17 15:25

At the risk of getting my hand slapped , again, I am going to wade in on this ..

I am just going to lay out a few scenarios,

1, Serversideperms false, HG enabled, you could take whatever anybody hops to your grid with, and happens to put down to work on. This to me equates to blatant attempt to steal.

2, Serversideperms true, HG enabled, you have to "GOD" things to take them, still theft of items that a person does not know or give you permission to take.

3, Serversideperms false, NO HG, Have Fun.

4, Serversideperms true, NO HG, Have Fun.

5, Serversideperms false, HG enabled, (server ignores the false and makes it true)

Just my 2 cents , but there is no reason for an HG enabled region to have serversideperms false.

Yes you can still "GOD" things, it is the nature of the beast, but that takes a conscious decision, and people traveling the HG generally know that.

But regardless the feature should work the way it is supposed to work , whatever that ends up being .

(0031562)
Mandarinka Tasty (reporter)
2017-01-17 22:17
edited on: 2017-01-18 00:57

There are not any questions about creating correctly and properly working permissions system. No doubts in it at all.

And actually the priority for now is preparing option:

serverside_object_permissions = true appropriately working in an every possible detail.

But developers, at least some of them, should also realise and remember the spirit of OpenSim, that has been living for the same beginning.

And that means freedom in making decisions.

So regardless any type of simulators and regardless of any character of grids there should still exist working options to change default settings.

Not everyone is enough advanced to change and compile the code by herself/himself and we are not allowed to take opportunity away from people who wish to decide in other way than individual developers wish.

That's simple in my opinion.

And blaming persons and even suggestions, that some options can be used in different ways should not belong to developer's task.

You are not a judge, never forget about it.

If person wants to set: serverside_object_permissions = false in her or his grid that is his/her own decision and no matter if the grid is commercial or not

HG or not etc. Let this person decide what option to set true and what to set false.

I repeat, the priority is making serverside_object_permissions = true in aspect of permissions to work in best way as possible for us to achieve.

But no one should remove things and base such decision on his/her individual point of view. Let people decide what they want.

If you want to remove things , then do that in your private environment.

Greetings

(0031563)
AliciaRaven (manager)
2017-01-17 22:57

When people talk about the freedom of opensim they always look at it from a one sided perspective. What about the freedom of creators to choose how their hard work is used? What you are saying is basically that because you don't agree with their choice to apply certain permissions to their creations that it is ok for you to remove them and ignore their copyright wishes.

The option to ignore permissions is a dated concept and works fine for closed grids where the creators know the choice of the grids owners is to ignore permissions. But today where content is moved around via the hypergrid and oars it has become more of a grey area.

I think that the decision to remove perms should be made on an individual basis using grid god powers, not just decided for all content that comes into the sim. A blanket copyright removal option basically.

Again i say that freedom goes BOTH WAYS, respect the creators freedom to choose how their work is used.
(0031564)
Mandarinka Tasty (reporter)
2017-01-18 00:08
edited on: 2017-01-18 00:58

I am also creator, and i have even not decided yet to move officially my creations from SL to my grids in Opensim. You wonder why ?

Because there are millions of ways of alterind and removing permissions.

But because I am also creator and user in same time, the decision to upload content belongs to me. I am not allowed to force grid owner to set this or other permission in his/her grid.

The decision belongs to myself, to upload or not upload.

Also , that is other topic, but i have also noticed many times, even officialy spoken, that copyrights must be respected in OpenSim, but if person takes content from SL, then all is ok and justified.

Because it is ok to steal from SL and not ok here ?

It is pure hypocrysy, I am only logical. I respect everyone, I want.

But only when logic is followed, not compromising.

(0031565)
AliciaRaven (manager)
2017-01-18 00:25

You proved my point, you are a creator and you will not upload your content because of options like this that take away your choice to protect it. But you still want to keep options like this is illogical. Yes the decision to upload is yours, and you have the freedom to make it free or include restrictions.
what your are basically saying is that theft is ok because content creators should expect it and not upload it in the first place. You are saying people should be free to ignore other peoples freedom and bypass their choices.

Also theft from SL is NOT ok, no one has "officially spoken" that it is acceptable. If you made it your self and fetch it over, then that is not theft.
(0031566)
Mandarinka Tasty (reporter)
2017-01-18 00:41
edited on: 2017-01-18 01:00

I consider that as very logical: person registers herself/himself = chooses virtual world ( grid ), reads informations, whether permissions work and how they work and finally decide to upload her/his content or not.

The opposite, grid owner decides to create, build hg grid with no permissions at all. And that is his/her authonomy, to make such decision.

Why to take such possibility from him or her away ?

PS: When you check original source of 95% of animations in OpenSim, you mostly find them in SL. why ? Because person has bought our ao at Vista, and has become an owner of the hud, that gives permission to upload them in Opensim?

But almost everyone does that and that is not fair.

(0031567)
aiaustin (developer)
2017-01-18 01:02
edited on: 2017-01-18 01:03

Mandarinka.. its me that is editing your comments to word wrap each para. I am only removing superflous newlines to make each paragraph easier to read. I hope I have not deleted any content at all. This is just to let you know. For some reason each of your comments comes in with two new line characters between lines inside paragraphs I have seen. Maybe cut and paste issue?

(0031568)
Mandarinka Tasty (reporter)
2017-01-18 01:15

ah Thank you Aiaustin. No problem :) i have thought, that there should be "space line" between lines. It was looking better for me. But i may write without it too :)
(0031569)
mewtwo0641 (reporter)
2017-01-18 01:51
edited on: 2017-01-18 01:55

In my opinion, I believe that instead of taking away the serverside_object_permissions option and functionality, establish a configurable grid policy in OpenSim.ini that can be tailored to each individual's need grid side.

For instance:

; Enforces serverside_object_permissions = true effectively forcing an OpenSim instance connecting to this grid to use the permissions module {true false} true
grid_enforce_permissions = true

; Enables or disables ability to save OARs for OpenSim instances connecting to this grid {true false} false
grid_allow_save_oar = false

; Enables or disables ability to load OARs for OpenSim instances connecting to this grid {true false} true
grid_allow_load_oar = true

; Enables or disables ability to save IARs for OpenSim instances connecting to this grid {true false} false
grid_allow_save_iar = false

; Enables or disables ability to load IARs for OpenSim instances connecting to this grid {true false} true
grid_allow_load_iar = true

These options would override a connecting OpenSim instance's ability to do these things while they are connected to that grid.

This would allow grid operators to protect against users who would try to abuse the system and connect with permissions disabled by simply configuring these values and let the grid service override their permissions setting. For those running their own grid services and that want a truly open and permissive environment they can configure accordingly too. And obviously these permissions wouldn't apply to Standalone instances since it wouldn't be connecting to anyone's grid and serverside_object_permissions should work as intended set true or false.

Everyone is happy and functionality doesn't have to be removed because of a few bad eggs out there.

(0031994)
mewtwo0641 (reporter)
2017-06-04 15:43

This is still an issue in Master. But I believeI've tracked down the cause of the issue to be that on IAR load; When loading the IAR to anyone but the original creator it seems to be assigning the owner of the object to the original creator instead of the person the archive is being loaded to resulting in the object becoming unwearable/unusable.

- Issue History
Date Modified Username Field Change
2017-01-16 18:06 mewtwo0641 New Issue
2017-01-16 18:17 mewtwo0641 Description Updated View Revisions
2017-01-16 18:24 mewtwo0641 Description Updated View Revisions
2017-01-17 00:47 UbitUmarov Note Added: 0031550
2017-01-17 03:46 mewtwo0641 Note Added: 0031551
2017-01-17 03:47 mewtwo0641 Note Edited: 0031551 View Revisions
2017-01-17 03:53 Mandarinka Tasty Note Added: 0031552
2017-01-17 04:01 mewtwo0641 Note Added: 0031553
2017-01-17 04:03 mewtwo0641 Note Edited: 0031553 View Revisions
2017-01-17 04:05 UbitUmarov Note Added: 0031554
2017-01-17 04:12 Mandarinka Tasty Note Added: 0031555
2017-01-17 04:14 UbitUmarov Note Added: 0031556
2017-01-17 12:05 aiaustin Note Added: 0031557
2017-01-17 12:06 aiaustin Note Edited: 0031557 View Revisions
2017-01-17 12:08 aiaustin Note Edited: 0031557 View Revisions
2017-01-17 12:09 aiaustin Note Edited: 0031557 View Revisions
2017-01-17 12:10 aiaustin Note Edited: 0031557 View Revisions
2017-01-17 12:10 aiaustin Note Edited: 0031557 View Revisions
2017-01-17 12:11 aiaustin Note Edited: 0031554 View Revisions
2017-01-17 12:11 aiaustin Note Edited: 0031555 View Revisions
2017-01-17 12:12 aiaustin Note Edited: 0031552 View Revisions
2017-01-17 12:13 aiaustin Note Edited: 0031555 View Revisions
2017-01-17 12:16 aiaustin Note Edited: 0031557 View Revisions
2017-01-17 12:17 aiaustin Note Edited: 0031557 View Revisions
2017-01-17 12:18 aiaustin Note Edited: 0031555 View Revisions
2017-01-17 12:37 mewtwo0641 Note Added: 0031558
2017-01-17 12:39 mewtwo0641 Note Edited: 0031558 View Revisions
2017-01-17 12:41 mewtwo0641 Note Edited: 0031558 View Revisions
2017-01-17 12:42 mewtwo0641 Note Edited: 0031558 View Revisions
2017-01-17 12:47 aiaustin Note Edited: 0031557 View Revisions
2017-01-17 12:47 aiaustin Note Edited: 0031557 View Revisions
2017-01-17 12:52 mewtwo0641 Note Edited: 0031558 View Revisions
2017-01-17 13:51 aiaustin Note Edited: 0031557 View Revisions
2017-01-17 14:43 UbitUmarov Note Added: 0031559
2017-01-17 15:19 watcher64 Note Added: 0031561
2017-01-17 15:21 watcher64 Note Edited: 0031561 View Revisions
2017-01-17 15:21 watcher64 Note Edited: 0031561 View Revisions
2017-01-17 15:25 watcher64 Note Edited: 0031561 View Revisions
2017-01-17 22:17 Mandarinka Tasty Note Added: 0031562
2017-01-17 22:57 AliciaRaven Note Added: 0031563
2017-01-18 00:08 Mandarinka Tasty Note Added: 0031564
2017-01-18 00:25 AliciaRaven Note Added: 0031565
2017-01-18 00:41 Mandarinka Tasty Note Added: 0031566
2017-01-18 00:42 Mandarinka Tasty Note Edited: 0031566 View Revisions
2017-01-18 00:54 aiaustin Note Edited: 0031562 View Revisions
2017-01-18 00:56 aiaustin Note Edited: 0031562 View Revisions
2017-01-18 00:57 aiaustin Note Edited: 0031562 View Revisions
2017-01-18 00:58 aiaustin Note Edited: 0031564 View Revisions
2017-01-18 01:00 aiaustin Note Edited: 0031566 View Revisions
2017-01-18 01:02 aiaustin Note Added: 0031567
2017-01-18 01:03 aiaustin Note Edited: 0031567 View Revisions
2017-01-18 01:15 Mandarinka Tasty Note Added: 0031568
2017-01-18 01:51 mewtwo0641 Note Added: 0031569
2017-01-18 01:52 mewtwo0641 Note Edited: 0031569 View Revisions
2017-01-18 01:52 mewtwo0641 Note Edited: 0031569 View Revisions
2017-01-18 01:55 mewtwo0641 Note Edited: 0031569 View Revisions
2017-06-04 15:43 mewtwo0641 Note Added: 0031994


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker