Owner or Group Scripts in LSL

This is just a quick post on an issue that is easy to overlook in making touch scripts work only for the owner or a group. If for example, you set an object to no group, that should include everybody – but it doesn’t! If, for example, you want a door that can be switched to owner or group only on certain occasions by altering its group, but at other times all people (no group) should be able to open that door simply by altering its group back to none, anybody who has a group selected will not be able to open the door as expected.

Try this:

default
{
    touch_start(integer touched)
    {
        if (llDetectedKey(0) == llGetOwner() || llSameGroup(llDetectedKey(0)) == TRUE )
        {
            llSay(0,"This works if you are the owner or in the same group. However, if you the object is in no group and you activate one of your groups, it will react counter-intuitively as though you are not in the same group as it.");
        }
    }
}

Here is a script that enables you to run the relevant tests:

default
{ 
    touch_start(integer n)
    {
        if (llDetectedKey(0) == llGetOwner()) llSay(0,"Owner");
        if (llDetectedGroup(0) == TRUE) llSay(0,"Same group - test one");
        if (llSameGroup(llDetectedKey(0)) == TRUE) llSay(0, "Same group - test two");
        if (llSameGroup(NULL_KEY) == TRUE) llSay(0,"No group");
    }
}

Here is the solution:

default
{
    touch_start(integer touched)
    {
        if (llDetectedKey(0) == llGetOwner() || llSameGroup(llDetectedKey(0)) == TRUE || llSameGroup(NULL_KEY) == TRUE) )        {
            llSay(0,"This works if you are the owner or in the same group. If the group has no valid key i.e. the object is in no group, you can now operate the script even if you have a group enabled.");
        }
    }
}

Sometimes simple things are worth documenting too đŸ™‚

TLS (“SSL”) Quirks in OpenSim

This is not a post about my ongoing struggles to make OpenSim work with TLS and communicate properly with other grids, using a transparent Nginx reverse proxy. I suspect there may be one or two bugs to report but I am still investigating numerous issues, particularly around why the XMLRPC method verify_agent seems to fail to reach the target grid consistently – is it my proxy settings or is it something in OpenSim?

I am going to write about the alleged “out of band” TLS settings, a topic which confused me for some time. You will find these in Robust[.HG].ini (for my earlier work on TLS for the simulator, please see my earlier post, which makes edits to OpenSim.ini). In fact, despite my earlier credence in this statement, it is potentially misleading. It is in fact possible to add a native HTTPS port to the simulator, to set it as the main listener port rather than as the additional port, and to set it up with TLS provided externally. There are some considerable quirks in this system – and one major drawback that means that you will continue to need to use an external reverse proxy like Nginx to operate a grid using TLS.

I will be studiously avoiding the common and erroneous use of the term SSL for TLS, since the use of SSL instead of its successor TLS for HTTPS and similar protocols has long been compromised and is both insecure and deprecated. In fact it is wisest only to use TLS versions 1.2 and 1.3 if at all possible, never version 1.0. It may still be necessary to use version 1.1 for some limited purposes but I shall not address that further here. Both 1.0 and 1.1 have been deprecated by major browsers since March 2020.

The settings in question under [Network] are https_listener, https_main and https_external (of which the latter remains undocumented, even in OpenSimDefaults.ini).

The first of these, https_listener = True, adds an additional secure HTTPS (TLS) port as documented. You will also need to set https_port = 9002 (or whatever suits your setup, but I am popularising 9002 and 9003 for the defaults for TLS), cert_path = “path/to/cert.p12” (location of the X509 certificate) and cert_pass = “yourpassword”, as well as possibly needing to look again under [Startup] at NoVerifyCertChain = true and NoVerifyCertHostname = true (set to false if you are using a certificate authority to validate your certificates via LetsEncrypt or some other authority).

The next setting https_main = True sets the main listener as the HTTPS port. However, whether by design or by oversight, it does not transfer any of the HTTP handlers (use show http-handlers on the Robust console to show these) to the HTTPS listener port. This is a problem for Hypergrid (and presumably for the purposes of all the other handlers too!) since you will be unable to verify the identity of the agent and the client without the relevant XMLRPC methods. For this reason, setting up a grid to use TLS still requires the use of Nginx as a reverse proxy. (I am still having problems getting this to work despite successful manual XMLRPC calls to the ports with cURL to check that the correct results are in fact returned from the server.) This quirk is really quite annoying but I do not know if there is some reason for it. Since this is the main public port, I can see no reason not to switch it over or duplicate these endpoints. Another less important quirk is that port is not replaced, irrespective of how you set https_main, and that https_port is additional, similar to the situation on the simulator that I documented in my earlier post. This is no problem: you don’t have to let it through your firewall.

Ed. [2022-02-18 10:58]: Are the missing HTTP handlers related to this commit?

The third quirk relates to the entirely undocumented https_external setting. I discovered this by looking at the code in Framework/NetworkServersInfo.cs (and, for example, in the OpenSim Mantis such as in this feature request). This is a very peculiar setting indeed because, if https_external = True and https_listener = True together, the https_port port will be added without TLS i.e. it will be reachable only by the protocol http:// and not by https:// on the server. It will then require an external proxy like Nginx to provide the latter (for which see my comments above on the ongoing issues that I am testing). In essence, despite the name https_port, it is then an additional HTTP port without any of the HTTP handlers that are provided on port. You then have two plain HTTP ports. That seems rather eccentric, but it works and is logical, though it is counter-intuitive. You wouldn’t guess this without some help, especially as it isn’t documented.

To summarise, the description of these settings as only being useful for “out of band” purposes like the remote console is still accurate because the HTTP handlers are not available, whether it is the secondary or the main public port on the Robust server. If these were transferred and/or duplicated then it follows that it would also be of primary use in setting up TLS on Robust without the need for a reverse proxy. I would like to see this happen: it might help with my struggles with the Hypergrid with TLS.

I hope this post is of use to OpenSim developers, testers and grid admins alike. I will document what I suspect may be problems/bugs in using TLS with reverse proxies in another post when I can (still testing).

Lastly, I repeat my assertion that this is a priority matter and that all grids should at least use TLS for the login server so that passwords are not broadcast in the clear – Ed. note that the SceneGate viewer actually warns you about this by default unless you tell it not to after the first time. That is the industry standard for a reason. I accept the arguments about the excessive overheads of encryption for other purposes, although I am reminded of SL being hacked by giant penises back in the day and thus suggest that it might be an idea to secure some other public data transmissions too. The overheads are not that much in practice on modern hardware and with modern compression standards, and you don’t need to use TLS on the internal port (usually 8003) unless you really need to open that up to the Internet i.e. simulators on remote machines will need to connect to your Robust services or you split services over multiple remote machines. Most of the rest of the Internet now uses HTTPS for almost everything, certainly for the Web, FTP, SSH, e-mail and so on. That bring me to a final observation: there are no TLS settings for the internal port in this situation, so you would still need to use Nginx as a reverse proxy for this. Correction: there is no separate setting but, when https_main = True and https_listener = True, both the private port and the https_port are served over HTTPS unless http_external is also set. Should this be documented more precisely? There is a use case for these settings existing in such a situation, although most people probably wouldn’t need to use them unless they anticipate running a public grid to which others can connect regions. It’s a bit problematic too if you want no HTTPS on the firewalled internal port (where there is no need for the encryption overhead) but you do want it on the public-facing port.