Annonymous users are able to move things, ignoring perms


#1

I had a new user come into earth today, and he was not logged in but he was still able to open the edit window and move things around. I dont know how long this has been going on but it is dangerous, something must have broken because I cant see this being by design.

The current system of locking entities is flawed because locking an entity effectively disables some scripts so I have to leave things unlocked so they work, now it seems just anybody can come along and move whatever isnt locked, even though I have anonymous set to only connect.

I hope someone can look at the permissions system and find out why an anonymous user can open the edit window and potentially mess stuff up.


#2

Yep,

It is a major flaw in the design because basically anyone grabbing anything is basically simply just manipulating the position of the objects, which requires edit permissions. It really needs rethink, but I think it might be too late.

However, have you tried looking into the server scripts that should allow you to lock the entity? it basically works like a entity script, but its the server controlling it, so it should be possible to lock the object.


#3

Thanks for the suggestion but locked objects dont allow interactive scripts to work. Another design flaw.

So what you are saying is…The idea that an anonymous visitor cannot edit objects is actually BS, and in fact anonymous visitors can come and trash whatever is not locked regardless of the permissions granted. So we are back to pretty much zero security.

Major design flaw you say? Feels like there’s no design.

And yet even though edit permissions are explicitly denied, they can still move stuff? This is simply unacceptable and I am hoping to hear that it is a bug and will be fixed.

I need a real answer from the devs please. How can I stop anonymous users from moving unlocked stuff and still allow them to come and look???
Because if I cant stop them then there is nothing here worth spending any more time on. The first griefer will laughingly trash the place and there’s nothing I can do to stop it.


#4

As in edit permissions being ability to move the object. I pointed this out a while ago to the devs when I deleted parts of the voice stress test cinema of parts that were not locked (with me having no other permissions than ability to connect) but It may need a re-brought up like many other issues that have been below the surface.

So I will make it public knowledge here exactly what to force the issue (as I reported this back when the stress test started to cait)

Basically right now permissions we have control ones ability to

  • Connect
  • Rez temp
  • Res permanent
  • ability to lock / unlock

Edit.js forexample controls the flag My Entities.canRez() && Entities.canRezTmp() it doesn’t stop you from opening edit entity list from the submenus nor does it stop you from running a script that deletes all entities that are unlocked in the domain or moving them. Meaning if a script doesn’t do a check it will do what they do.

Worse I found this by being tempted to deploy the :fox_face: bomb during the stress test by putting it into a random unlocked entity during the voice tests but decided against it. Because it is just a script that runs on on client side, it would have been nigh impossible to find as there is no identity to who spawned an entity, just who edited one last, meaning if you force everyone to edit that entity, there is no origin to be traced.

It is also why they made the cloneable worklist to make a workaround to make interactable objects from locked objects. (As in make temporary clones) which also is useful
For other stuff. Because if you can’t edit the user data it’s the same as locking it for some scripts.

So I’d suggest for hifi devs to add a new check similar to locking on the server side: that if you have the ability to res permanent you should then be able to edit permanent. If you don’t you can’t do anything with entities that are not temporary. Similarly if you cannot rezTemp, you will not be able to edit temp.

That would create three layers of permissions.

There are also other methods to cause havoc, which I have demonstrated, such as the :fox_face: bomb.


#5

@Adrian - are you set up to compile your own domain-server / assignment-client builds from source?

If so we could talk about prototyping something like ACL perms at the Entity property level.


#6

Kind of, we do compile our own server on Linux using an update and compile script that @Coal has written and manages.
So if its a case of adding some new dependencies once, I guess that would be possible, but if the source needs to be modified every time we compile then it wont work for us (without a lot of work).

I am all for anything that improves the security and permissions, but from past experience, in our world of never knowing what will be changed next, I am now unwilling to put much effort into something that we have no idea of where its heading.
This is why I asked for a response from a dev.

The system feels more unfinished than flawed, and I am hoping that it is going to be worked on and improved, in which case there is little point in making drastic changes to our personal builds, we can just lock everything down and be patient while we wait for the work to be done.

But we dont know whats happening so I ask if we can get some kind of indication as to what the devs plan is regarding this particular issue. Please.


#7

Just to make sure the option is known… you might want to check out Server settings -> Show Advanced -> Entity Server Settings -> Filter Entity Edits feature. (this is how certain builder restrictions get enforced on Welcome, for example)