Mod Blacklist

[Sayomie555]

On the FTB server that i am running when players log on with some mods that are not on the server, It causes the server TPS to go from 20 tp 10-15.

 

I would like to suggest a config or a folder where server managers can drop mods to be blacklisted so that servers can try and block X-Ray mods and mods that may cause lag to the server. Another method that this could also be done is to add a option to the forge config to not allow players to log on with mods that are not on the server or white-listed by the server.

 

Thx

 

 

[luacs1998]

Meh, that's the server admin's problem.

[Sayomie555]

Currently there is no way to black list or white list mods that players can log onto the server with. I recognize that it is server admins problem but currently there are no tools for the server admin to use.

[Cloudy]

What would tell the server which mods it has joined with? The client.

 

You see the issue there? A client could just lie about which mods it has installed - and you'd be back to square one.

[Sayomie555]

It is not so much to stop those that want to purposely cause harm to the server, that is near impossible to stop. It is to prevent those who do not know better from logging on with a mod on their client that many cause lag to the server.

 

On the FTB server that I admin on when I logged on with Treecapitator it caused the server TPS to drop from 20-12. If it was someone else who had the mod on their client i would never know and the server would just be laggy, If there was a tool to allow only certain mods then that could easily be prevented.

[Cloudy]

Except there's no way that the mod on the client can affect the server tps. It has no control over the server logic.

[thebest108]

Also, there is no way to blacklist client mods. If the client had some extra mods or hacks then why would it tell the server?

[JaredBGreat]

Hmmm...

 

I'd love it if forge disable forge-based mods not used on the server, for the good of the person with the mod (so they don't try to do or make things the client thinnks are allowed but won't work on the server).  Similarly, I'd like it if clients had a cloud-like feature of loading mod material from the servers mods folder.  With things like that, someone could log into modded folders without having to change there Minecraft everytime they switched servers, and server admins could run modded servers without everyone having to have the same mods.

 

As for cheat mods, or any non-forge mod, I don't see how this is really feasible, or even possible -- sure, you could make forge mod loader poll for and anounce mods it has loaded, but no way to prevent other mods from being hacked in.  Bukkit has pluggins that claim to check "suspicious" behavior, but I'm always concerned than such thing might produce false positive, punishing innocent players, while not catching all cheats.

 

I don't think the server performance should be effected by client mods directly, but I don't really know about ther.

[JaredBGreat]

  On 2/5/2013 at 9:04 AM, diesieben07 said:

LexManos has stated a few times that this is not going to happen. And for good reasons: Server owners can be evil and mods can be, too. A mod can do anything on your computer. And if a server can make you download a mod then thats a huge security issue.

 

I actually had not thought of this when I wrote before, but I have since and been concerned about it.  However, it doesn't seem to me that it would be any more dangerous than installing them locally, especially compared to the only style mods where you open the minecraft.jar directly and drop things in.  A determined cracker who want to turn Minecraft into spyware could, anyway -- but making access default ot the serever woudl be atleast marginally safer.

[JaredBGreat]

  On 2/7/2013 at 1:05 PM, diesieben07 said:

If a user installs a mod themselves it's their problem. Same if you install new software on your computer. You tell the computer to install it.

But if you join a server and that triggers a Mod-Installation that is non-intuitive and most users won't think of the fact, that that Mod installation could possibly just format their harddrive.

 

I'm not sure I aggree with that specific argument, since a well make API could (and should) warn the player and ask their permission first, making it more a convenience for the player.  Still, as I think about it I am starting to see other risks, specifically, knowing if the mod being install is what it claims to be or comes from where it claims to.

 

I suppose the real danger is that a cracker could install there spyware or malware into someone else's mod, so that you think you're getting Twilight Forest or The Aether, but are really getting a modified version of the mod that has dangers even though the real version is safe (and you wouldn't know you weren't getting the original). Hmmm, I wish there was a safe way to make that work, just not sure there is any more -- at least not with Minecraft, not with a game that already exists. Now, if someone were to create a sand-box type game that included full vertualization around the game itself, isolating it from the rest of the system with modding the core game files in mind, that would be different.  I don't think there's a way to do that with Minecraft (not based on its own programming, at the very least).

 

Its really disappointing, since was wanting to use multiplayer with specifc mods, but feel like an a** telling everyone they must have the mods I happen to like to play (and none that conflict with it) -- yet this is why I picked Forge over Bukkit (and still haven't gotten good result from BukkitForge), and, for that mater, why I set up a server in the first place. 

[diamondq]

Well, technically it is possible to implement this feature securely. It's the Java Platform Security, using Protection Domains and security policies. By enabling the Java security, and then defining the appropriate security policies, you could control what permissions a given mod has. The most obvious permission "don't allow it to execute arbitrary commands" (ie. format C:\ ).

 

The downside is that mod authors would have to make sure that their mods complied to the generic policy, or instructed the user on the 'elevated privileges' that they require to operate.

 

Personally, I've always felt that Forge should isolate each mod in it's own ClassLoader, which:

• provides the starting point for this type of security
  
• reduces the chances for conflicts between mods (I don't know how many times I've run into problems where multiple mods all include some 'standard mod's API (like ComputerCraft or IC2) but all slightly different versions)
  
• makes it much easier to 'turn on' and 'turn off' mods
  
• makes it much easier to identify a mod during runtime (ie. a client/server profiler that tells you which mod is causing all the lag)
  

[LexManos]

If it was simple, it would be done, lets just leave it at that. Its a pain in the ass and java's security is a joke. The point is, we will not be distributing or facilitating the distributions and installations of mods automatically in a system like this. We do not have the resources to manage the backend that this would need. This has all been discussed and debated many times with all of the rel event people. It's not gunna happen officially from Forge.