MC-59653Signs 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 by3
![[Mod] turbo](../../../data/avatars/users/92867.png){kind=small}
LowCreated Issue:
Signs with clickEvents only check permission in spawn-protection
Signs with clickEvents only check player permissions(if the player is OP) if that sign is inside the spawn-protection area set by server.properties.
This bug only works with signs. it does not work with books nor tellraw.
I have changed my spawn-protection area and the bug still persists.
Environment
Server: CentOS 6.5, 32GB RAM, Java 1.7
Client: Windows 7, 8GB RAM, Java 1.7
Signs with clickEvents only check player permissions(if the player is OP) if that sign is inside the spawn-protection area set by server.properties.
This bug only works with signs. it does not work with books nor tellraw.
I have changed my spawn-protection area and the bug still persists.
Pastebin for the command used: http://pastebin.com/rKwJmCJt
is duplicated by
relates to
is duplicated by
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
Signs with clickEvents only check player permissions(if the player is OP) if that sign is inside the spawn-protection area set by server.properties.
This bug only works with signs. it does not work with books nor tellraw.
I have changed my spawn-protection area and the bug still persists.
Pastebin for the command used: http://pastebin.com/rKwJmCJtThe bug
Signs that contain a clickEvent are only checked for operator permissions if clicked inside of spawn-protection area set by server.properties.
How to reproduce
- Start a Minecraft server.
- Set the spawn-protection field in the server.properties file to 10.
- Run:
/give @p minecraft:oak_sign{BlockEntityTag:{Text1:"{\"text\":\"Click me\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"fill ~ ~1 ~ ~ ~2 ~ redstone_block\"}}"},display:{Name:"{\"text\":\"MC-59653\"}"}} 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.
→- Click the sign outside the spawn protection area.
→
Server: CentOS 6.5, 32GB RAM, Java 1.7
Client: Windows 7, 8GB RAM, Java 1.7
![[Bot] Arisa](../../../data/assets/gravatar/mustek2.png){kind=small}
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
![[Mod] NeunEinser](../../../data/avatars/users/39263.png){kind=small}
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 minecraft:oak_sign{BlockEntityTag:{Text1:"{\"text\":\"Click me\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"fill ~ ~1 ~ ~ ~2 ~ redstone_block\"}}"},display:{Name:"{\"text\":\"MC-59653\"}"}} 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.
→- Click the sign outside the spawn protection area.
→
![[Mod] Asteraoth](../../../data/avatars/users/92886.png){kind=small}
relates to
relates to
relates to
![[Mod] Les3awe](../../../data/avatars/users/79847.png){kind=small}
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
is duplicated by
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
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 @pminecraft:oak_sign{BlockEntityTag:{Text1:"{\"text\":\"Click me\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"fill ~ ~1 ~ ~ ~2 ~ redstone_block\"}}"},display:{Name:"{\"text\":\"MC-59653\"}"}} 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.
→- Click the sign outside the spawn protection area.
→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{display:{Name:'{"text":"MC-59653"}'},BlockEntityTag:{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.
→- Click the sign outside the spawn protection area.
→
relates to
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{display:{Name:'{"text":"MC-59653"}'},BlockEntityTag:{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.
→- Click the sign outside the spawn protection area.
→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:
I think it's this now: /give @p oak_sign[item_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.
→- Click the sign outside the spawn protection area.
→
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:
I think it's this now:/give @p oak_sign[item_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.
→- Click the sign outside the spawn protection area.
→
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[item_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.
→- Click the sign outside the spawn protection area.
→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.
→- Click the sign outside the spawn protection area.
→
Dupe of MC-59653
Could relate to MC-59653
Dupe of MC-59653
The bug
As mentioned in the title, non-op players can run op commands from signs (using "run_command" "clickEvent", MC-59653), but not from written books (also using the "run_command" "clickEvent" mechanic). If that's not a bug, it's definitely inconsistent.
How to reproduce
- Create a new world with cheats disabled
- Open the world to LAN with cheats enabled
- Give yourself a written book with a "run_command" clickEvent:
/give @s written_book[written_book_content={title:"MC-201807",author:"Author",pages:['{"text":"Test","clickEvent":{"action":"run_command","value":"/give @s stone"}}']}] 1 - Close and reopen the world
- Open the book and click on the word "Test"
→ The command fails (you are not given a block of stone) - Open the world to LAN again with cheats enabled
- Open the book and click on the word "Test"
→ The command runs successfully (you are given a block of stone)
WOW i didn't new this works!
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.
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.
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.
Tested in 14w29b and is still present.
Like WolfieMario 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 QwertyuiopThePie 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.
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:
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.
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.
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.
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.
Confirmed for
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
Confirmed for 1.9 release
Confirmed for 1.9.4.
Confirmed for 1.10.
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.
Confirmed for 1.11
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!
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.
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.