[MC-59653] Signs with clickEvents only check permission in spawn-protection

The bug

Signs that contain a clickEvent are only checked for operator permissions if clicked inside of spawn-protection area set by server.properties.

Note: Signs being able to execute commands regardless of executor permissions is likely widely used in adventure maps. It does not directly impose a security vulnerability because placing such signs with clickEvent requires operator permissions. It is similar to placing a command block containing a command: Placing the command block requires operator permissions, but anyone can afterwards place redstone next to it to activate it.

How to reproduce

Start a Minecraft server.
Set the spawn-protection field in the server.properties file to 10.

Run:

/give @p oak_sign[custom_name='{"text":"MC-59653"}',block_entity_data={id:"minecraft:oak_sign",front_text:{messages:['{"text":"Click me","clickEvent":{"action":"run_command","value":"fill ~ ~1 ~ ~ ~2 ~ redstone_block"}}','{"text":""}','{"text":""}','{"text":""}']}}] 2

Place one sign inside the spawn-protection area and one sign outside the spawn-protection area.
Deop yourself, but make sure theres atleast one other player opped, so spawn protection is active.
Click the sign inside the spawn protection area.
→ ✔ Sign unsuccessfully used, no blocks were placed
Click the sign outside the spawn protection area.
→ ❌ Sign succesfully used, two redstone blocks are placed above the sign

Linked issues

is duplicated by 3

MC-79761 Sign Click Events disabled in Spawn Protection Resolved

MC-106567 JSON commands embedded in a sign only activate for some players Resolved

MC-223779 Sign clickEvent unusable in Spawn Protection Resolved

relates to 2

MC-201807 Non-ops cannot run op commands from books Reopened

MC-36093 Signs and hanging signs destroyed within spawn protection don't retain their contents for the client Reopened

Comments 17

Robin T. 2014-06-30T14:04:31Z

WOW i didn't new this works!

WolfieMario 2014-07-11T04:25:08Z

Works as Intended, or Invalid, from what I can tell.

Spawn Protection blocks click events of many kinds. It prevents non-OPs from opening/closing doors, for example. It also prevents players from using commands such as /say and /trigger through spawn-protected signs. There is no command-level permission checking involved; it only checks whether the player has permission to interact with blocks at all in the area.

Outside of spawn-protected zones, sign commands are not restricted. This is because players cannot create signs with commands on them. It is pretty much the same as activating a command block with a button: inside spawn protection, non-OPs can't trigger it at all. Outside spawn protection, non-OPs can freely trigger it, but cannot edit the commands they run.

You should avoid leaving command signs lying around for the same reason you should avoid leaving command blocks lying around.

QwertyuiopThePie 2014-07-11T04:41:24Z

It's not that this causes issues. In fact, it's preferable. The problem is the inconsistency.

By all means, this is a convenience, but the same logic also applies to tellraw commands, and book commands, etc, none of which have the same effect. Yet, signs work just fine.

Believe me, nobody here thinks this bug is a bad thing. But it is a bug. If it wasn't, it'd be more consistent.

WolfieMario 2014-07-11T05:45:45Z

I don't see how it's inconsistent. Spawn protection prevents non-OPs from interacting with blocks, but has no effect on interactions with chat or books. It prevents you from right-clicking a sign for the same reason it prevents you from right-clicking a button attached to a command block.

The reason /tellraw commands and books require OP for executing arbitrary commands is security. A mod can spoof a /tellraw message or book interaction packet with arbitrary commands attached. The server has to validate it, but doesn't actually have access to the chat on a client's screen or the specific pixels of a book the player clicked on. This is simply because of how these two run_command vectors work, and as a result, the server's only option is to require the player to be OP.

The reason signs don't require players to be OP is because the client only sends a clickEvent packet to the server, telling it the coordinates of the block which was right-clicked. The server already validates these packets by making sure the player is within range of the clicked block and (as far as I am aware) has a clear line of sight to it. At this point, the server just has to check what commands are on the sign, and can freely run them whether or not the user is OP. I don't see how it could've been implemented this way on accident.

To sum it up, the reason the OP restriction applies to tellraw and books is because in both cases, the client sends the server a command to be run. The reason it does not apply to signs is because the client only sends the sign's coordinates, and the commands themselves are purely server-side. It's not obvious why it works this way, but it's not a bug, and also has nothing to do with spawn protection.

Cody Senmori 2014-07-20T18:25:48Z

Tested in 14w29b and is still present.

Like @unknown said, the reason tellraw and books require OP for executing commands is security. Those two examples use the same JSON formatting that signs are capable of using, yet only signs are not checked if the player can issue said command(s).

As far as I know, all events are passed to the server for processing and the server determines if the player can issue said commands(as proven by trying to issue commands via books outside spawn protection). It makes no sense to only check commands that are inside signs when the activating player is also inside spawn protection.

Yes, like @unknown said, it's more of a convenience issue and players creating these signs shouldn't leave them out and about but it happens and, sometimes, it's easier to do just that.

7 more comments

WolfieMario 2014-07-21T01:09:52Z

See MC-61577: "CommandStats are not used when a command sign is right-clicked by non-OPs". Searge fixed this, making it fairly clear that non-OPs are intended to be able to run OP commands through signs, as much as they can run them through command blocks.

Look at it from a different angle: when a book/chat tellraw is clicked, the player executes the command. When a sign is right-clicked, the sign executes all top-level commands present in its JSON. This is very different from standard tellraw behavior, and more in-line with command block behavior:

The command's user is not the player who right-clicked it. This makes commands like /kill and /tp fail unless you give the player as an argument or proxy them via /execute.
Signs are able to execute commands up to as long as a command block's length limit. Books and tellraw are limited to the longest command a player can type, which is much smaller.
Signs do not need to prefix commands with a / slash, again similar to command blocks.
The coordinates of the sign are used, rather than the player's coordinates. This is very useful for signs which modify blocks or spawn structures. Once again, you can proxy by /execute if you really need to use the player's coordinates instead.
The sign's own CommandStats are used to store the command's results, rather than the player's CommandStats. This is the entire reason signs support the CommandStats tag.
A sign does not check which letter is clicked on. All top-level commands (a maximum of four) are executed, and nested commands are ignored. This works even if the sign is right-clicked on a part which does not contain text, such as the post or the backside.
A sign cannot be activated inside a spawn-protected area, as your ticket indicates. Last I checked, this behavior is consistent with the fact that doors cannot be opened and buttons cannot activate redstone (or by extension, command blocks) in spawn-protected areas.

It's easier to not think of signs the same way as books and tellraw, and helpful to think of them like command blocks. The syntax similarity is misleading if you're used to tellraw, but signs work very differently, and are intended to do so because it makes them much more useful. And it couldn't have been an accident; signs actually have a dedicated CommandExecutor class in the code.

It makes no sense to only check commands that are inside signs when the activating player is also inside spawn protection.

That's because this isn't what the game does. It checks that the sign (not the player) is inside spawn protection, and does not check what commands the sign has. The game will even block a player from running a "/me says Hello" sign, despite /tellraw and JSON books permitting non-OP players to use the /me command.

players creating these signs shouldn't leave them out and about but it happens and, sometimes, it's easier to do just that.

The same applies to leaving command blocks lying around. You really shouldn't do it, because ordinary players can activate them. There are also perfectly legitimate reasons to let ordinary players activate signs: I've seen a Reddit post where it was used in a portable shop system, and I'm personally working on a magic system which uses them. I don't think misleading syntax is a reason to remove existing and intended features.

galaxy_2alex 2014-12-21T18:59:17Z

Is this still a concern in the current Minecraft version? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases. If this has been done, we can reopen the issue.

Keep in mind that the "Resolved"-Status on this ticket just means "Answered", and that we are waiting for further information on whether this issue still exists or not. We will reopen it as soon as the requested information has been delivered.

marcono1234 2015-04-18T20:00:27Z

Confirmed for

1.8.4

Thomas Hall 2015-08-14T03:38:49Z

The problem with this (as recently as the 1.9 snapshots)
is that it checks the block interaction with the sign ONLY on spawn chunks. What this means is that I can't place command signs around my server spawn chunks to allow non-ops to teleport to areas set aside for them. Buttons too are disabled for non-ops on spawn chunks. My argument isn't that signs should check-op everywhere, it's that they shouldn't check op ANYWHERE, so as to allow you to let non-ops interact with the signs in spawn.

Edit: The above players wish for check-op everywhere, but that is a problem. Instead, I propose an exception for interaction with blocks for signs

M. C. 2016-03-19T22:50:38Z

Confirmed for 1.9 release

Keith 2016-06-08T01:41:56Z

Confirmed for 1.9.4.

Keith 2016-06-08T23:19:32Z

Confirmed for 1.10.

bob 2016-11-06T11:11:30Z

Is this still an issue in the latest snapshot 16w44a? If so please update the affected versions.

This is an automated comment on any open or reopened issue with out-of-date affected versions.

M. C. 2016-11-18T02:16:02Z

Confirmed for 1.11

Uriel Salischiker 2018-10-02T20:24:12Z

Is this still a issue in the latest version of the game(currently 1.13.1)?

If so, please add it to the affected versions, thanks!

user-f2760 2021-01-19T13:31:39Z

Confirmed for 20w51a, I should add that the fact they CAN run commands without permission is used by map makers a lot, and the spawn protection checking should probably be removed instead.

M D 2021-04-20T23:21:58Z

Confirmed for 21w15a
Apologies for posting a duplicate issue, did not see this one despite a searching. Server spawn areas seem like the use case this function was nearly made for, and it's a shame they still do not work as such.