MantisBT - opensim
View Issue Details
0008120opensim[REGION] OpenSim Corepublic2017-01-16 18:062017-01-18 01:51
mewtwo0641 
 
normalblockalways
newopen 
0.9.0 
 
Standalone (Multiple Regions)
ubODE
.NET / Windows64
None
0008120: Various issues with serverside_object_permissions = false
Testing 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.
1. 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
No tags attached.
Issue History
2017-01-16 18:06mewtwo0641New Issue
2017-01-16 18:17mewtwo0641Description Updatedbug_revision_view_page.php?rev_id=5932#r5932
2017-01-16 18:24mewtwo0641Description Updatedbug_revision_view_page.php?rev_id=5933#r5933
2017-01-17 00:47UbitUmarovNote Added: 0031550
2017-01-17 03:46mewtwo0641Note Added: 0031551
2017-01-17 03:47mewtwo0641Note Edited: 0031551bug_revision_view_page.php?bugnote_id=31551#r5935
2017-01-17 03:53Mandarinka TastyNote Added: 0031552
2017-01-17 04:01mewtwo0641Note Added: 0031553
2017-01-17 04:03mewtwo0641Note Edited: 0031553bug_revision_view_page.php?bugnote_id=31553#r5937
2017-01-17 04:05UbitUmarovNote Added: 0031554
2017-01-17 04:12Mandarinka TastyNote Added: 0031555
2017-01-17 04:14UbitUmarovNote Added: 0031556
2017-01-17 12:05aiaustinNote Added: 0031557
2017-01-17 12:06aiaustinNote Edited: 0031557bug_revision_view_page.php?bugnote_id=31557#r5939
2017-01-17 12:08aiaustinNote Edited: 0031557bug_revision_view_page.php?bugnote_id=31557#r5940
2017-01-17 12:09aiaustinNote Edited: 0031557bug_revision_view_page.php?bugnote_id=31557#r5941
2017-01-17 12:10aiaustinNote Edited: 0031557bug_revision_view_page.php?bugnote_id=31557#r5942
2017-01-17 12:10aiaustinNote Edited: 0031557bug_revision_view_page.php?bugnote_id=31557#r5943
2017-01-17 12:11aiaustinNote Edited: 0031554bug_revision_view_page.php?bugnote_id=31554#r5945
2017-01-17 12:11aiaustinNote Edited: 0031555bug_revision_view_page.php?bugnote_id=31555#r5947
2017-01-17 12:12aiaustinNote Edited: 0031552bug_revision_view_page.php?bugnote_id=31552#r5949
2017-01-17 12:13aiaustinNote Edited: 0031555bug_revision_view_page.php?bugnote_id=31555#r5950
2017-01-17 12:16aiaustinNote Edited: 0031557bug_revision_view_page.php?bugnote_id=31557#r5951
2017-01-17 12:17aiaustinNote Edited: 0031557bug_revision_view_page.php?bugnote_id=31557#r5952
2017-01-17 12:18aiaustinNote Edited: 0031555bug_revision_view_page.php?bugnote_id=31555#r5953
2017-01-17 12:37mewtwo0641Note Added: 0031558
2017-01-17 12:39mewtwo0641Note Edited: 0031558bug_revision_view_page.php?bugnote_id=31558#r5955
2017-01-17 12:41mewtwo0641Note Edited: 0031558bug_revision_view_page.php?bugnote_id=31558#r5956
2017-01-17 12:42mewtwo0641Note Edited: 0031558bug_revision_view_page.php?bugnote_id=31558#r5957
2017-01-17 12:47aiaustinNote Edited: 0031557bug_revision_view_page.php?bugnote_id=31557#r5958
2017-01-17 12:47aiaustinNote Edited: 0031557bug_revision_view_page.php?bugnote_id=31557#r5959
2017-01-17 12:52mewtwo0641Note Edited: 0031558bug_revision_view_page.php?bugnote_id=31558#r5960
2017-01-17 13:51aiaustinNote Edited: 0031557bug_revision_view_page.php?bugnote_id=31557#r5961
2017-01-17 14:43UbitUmarovNote Added: 0031559
2017-01-17 15:19watcher64Note Added: 0031561
2017-01-17 15:21watcher64Note Edited: 0031561bug_revision_view_page.php?bugnote_id=31561#r5963
2017-01-17 15:21watcher64Note Edited: 0031561bug_revision_view_page.php?bugnote_id=31561#r5964
2017-01-17 15:25watcher64Note Edited: 0031561bug_revision_view_page.php?bugnote_id=31561#r5965
2017-01-17 22:17Mandarinka TastyNote Added: 0031562
2017-01-17 22:57AliciaRavenNote Added: 0031563
2017-01-18 00:08Mandarinka TastyNote Added: 0031564
2017-01-18 00:25AliciaRavenNote Added: 0031565
2017-01-18 00:41Mandarinka TastyNote Added: 0031566
2017-01-18 00:42Mandarinka TastyNote Edited: 0031566bug_revision_view_page.php?bugnote_id=31566#r5967
2017-01-18 00:54aiaustinNote Edited: 0031562bug_revision_view_page.php?bugnote_id=31562#r5969
2017-01-18 00:56aiaustinNote Edited: 0031562bug_revision_view_page.php?bugnote_id=31562#r5970
2017-01-18 00:57aiaustinNote Edited: 0031562bug_revision_view_page.php?bugnote_id=31562#r5971
2017-01-18 00:58aiaustinNote Edited: 0031564bug_revision_view_page.php?bugnote_id=31564#r5973
2017-01-18 01:00aiaustinNote Edited: 0031566bug_revision_view_page.php?bugnote_id=31566#r5974
2017-01-18 01:02aiaustinNote Added: 0031567
2017-01-18 01:03aiaustinNote Edited: 0031567bug_revision_view_page.php?bugnote_id=31567#r5976
2017-01-18 01:15Mandarinka TastyNote Added: 0031568
2017-01-18 01:51mewtwo0641Note Added: 0031569
2017-01-18 01:52mewtwo0641Note Edited: 0031569bug_revision_view_page.php?bugnote_id=31569#r5978
2017-01-18 01:52mewtwo0641Note Edited: 0031569bug_revision_view_page.php?bugnote_id=31569#r5979
2017-01-18 01:55mewtwo0641Note Edited: 0031569bug_revision_view_page.php?bugnote_id=31569#r5980

Notes
(0031550)
UbitUmarov   
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   
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   
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   
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   
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   
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   
2017-01-17 04:14   
what part of "obvious" don't you understand?
(0031557)
aiaustin   
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   
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   
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   
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   
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   
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   
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   
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   
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   
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   
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   
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.