DEBUG_CHANNEL security
complete
WolfGang Senizen
Problem
When scripts error they send the error on the debug channel, publicly for everyone.
Given that we are now getting more advanced and useful errors.
These messages are possibly going to to start becoming sensitive, as they expose information about the script itself.
This mostly affects
SLua
and LSL/Luau
, it could possibly extend as an issue to the others if their debugging is also improved.Fix?
I think we need a 3 part solution.
- Errors on 0x7FFFFFFFneed to go to only the object owner, (and maybe objects owned by said owner?)
- Scripts need a debug checkbox/flag? --!debug? to enable or disable verbose errors.
- ll.RegionSayTo(ll.GetOwner(),0x7FFFFFFF,"debug")to also send messages to the viewer like the other chat functions do
The first solves the general problem while writing scripts.
The Second is to prevent exposing sensitive information to end users.
The third to allow creators to send manual debug messages privately as well
Side Effects
This will possibly break content that listens for errors on those channels to perform certain actions.
I would suggest maybe not changing the behavior of
llSay
, llShout
, llWhipser
, and llRegionSay
as if scripts are deliberately and publicly speaking on that channel that behavior may be desired.Log In
H
Harold Linden
complete
Users who don't have modify permissions will now just receive a "runtime error" message when the script fails rather than a full traceback.
Currently you'll receive a "runtime error"
in addition to
a detailed error report if you are the owner and have modify perms, this will be addressed in a future update.Thanks again for sending this in!
H
Harold Linden
We've finished a fix that will go out in a future roll. It will send a sanitized error to all users / scripts (generally just "runtime error".) A more detailed error with the error string and traceback will be sent directly to the owner's viewer on
DEBUG_CHANNEL
if script permissions allow sending more detailed info.WolfGang Senizen
Harold Linden
Looks like its mostly working, except possible double sending.
My full perm script throws error I receive the full error message in the error dialog. Other listening scripts receive
[script:New Script] Script run-time error
runtime error
An no mod script i cause to error give me and listening objects
[script:New Script] Script run-time error
runtime error
So apart from the double sending seems ok, unless that is intended.
H
Harold Linden
WolfGang Senizen Yeah the double-sending is difficult to avoid unfortunately. There's no concept of "broadcast this message to everyone except this specific person" in the simulator, so the best we were able to manage quickly is "send something general to everyone, and later send something more specific to this specific person".
Jamesp1989 Resident
Harold Linden is this something a future viewer update could address ?
H
Harold Linden
Jamesp1989 Resident It's something we'll have to change on the server
H
Harold Linden
in progress
Signal Linden
tracked
Thanks for the report! We're still working out what kind of error detail we want to send to non-creators of scripts, since it might still be useful for users to be able to report include the stack in reports to creators. We're just going to make the stack traces private for now, and later include a flag that allows script authors to specify what level of detail to include in user-facing errors.
WolfGang Senizen
Signal Linden
What does creator mean in this case?
I would suggest tying it to the owner and has modify perms.
H
Harold Linden
WolfGang Senizen
Yep! We should be using
is_owner + has_mod_perms
for the stacktraces now. Are you able confirm you don't receive stacktraces for other users' scripts anymore?WolfGang Senizen
Harold Linden
Tested on
Luau 2025-03-20.13979942511
I see no change at the moment
I see errors in the following scenarios
- Other user crashes script they are working on
- No mod script in no mod object given to me
- No mod script in mod object given to me
H
Harold Linden
WolfGang Senizen
Was afraid of that. We'll get that fixed, thanks for following up!
Nelson Jenkins
I'm not really sure why script errors were ever sent over the public
DEBUG_CHANNEL
to begin with. Chatting straight to DEBUG_CHANNEL
for non-VM-generated errors never made sense to me - I just send all of my logs via llOwnerSay (mostly) depending on the loglevel set in a linkset data value. IMO, end-users should never see DEBUG_CHANNEL
errors unless they are purposefully trying to break things, in which case I don't think everyone within 100m needs to hear about it.Seems like the easiest solution is to make stack traces a compile-time option. If you want to show stack traces to end-users, check the box. If you don't, for whatever reason, uncheck it. I think the security implications would only apply for a few very limited categories of scripts. In those cases, those problems should be revealed and solved during testing, not after release.
If that's really not workable, maybe a way to trigger an event in another script with the stack trace, so the scripter can handle it however they want? Apparently llResetOtherScript is capable of resetting crashed scripts now (showing my age here) so it'd be possible to implement an error reporting watchdog of some kind...
Tornado Siren
Really useful debug is great, but it needs to be done with consideration to the fact Second Life, unlike a lot of other Lua backed game experiences, has a permission system security model that is heavily relied upon by the creators on the platform for keeping secrets safe.
Some form of verbosity control for errors post-alpha period would be great. Ideally I see this as a dropdown in the editor, the same as compiler is now, and maybe even something the script can edit on the fly for in situ debugging for inworld support.
I'd like to see options to the effect of:
- "An error happened in 'script.lua'" <- Nice and vague, security through obscurity!
- "An error happened in 'script.lua:43' - brief note of type of error" <- Lot like LSL errors have traditionally been!
- "An error happened in 'script.lua:43' - stack trace" <- Super useful, but can be considered a security issue to some implementations.
WolfGang Senizen
It's already been brought up, that maybe a
DEBUG_LEVEL
of sorts is more desirable.So that we can get
Error happened
, This type of error happened
, and This type of error happened here
as separate types of debug.