Posts: 783
	Threads: 12
	Joined: Jan 2014
	
Thanks: 2
	Given 75 thank(s) in 62 post(s)
	 
	
	
		My point is not that its difficult just that there are a lot of parameters and command line arguments is probably not the best way of handling this. I am thinking that maybe a second ini file with the overrides, which the hosting provider can set to unwritable by the user, may be the best option.
	
	
	
	
	
 
 
	
	
	
		
	Posts: 116
	Threads: 3
	Joined: Sep 2014
	
Thanks: 31
	Given 16 thank(s) in 11 post(s)
	 
	
	
		I believe that optional ini file with overrides is the most reasonable option. 
Also, i don't think plugin sandboxing is really that important - it'd be nice to have, but your average minecraft user won't use it to mess things up on purpose.
	
	
	
	
	
 
 
	
	
	
		
	Posts: 783
	Threads: 12
	Joined: Jan 2014
	
Thanks: 2
	Given 75 thank(s) in 62 post(s)
	 
	
	
		I agree, and think that sandboxing is unneeded in the initial implementation, but whatever option we choose should be able to handle it.
	
	
	
	
	
 
 
	
	
	
		
	Posts: 783
	Threads: 12
	Joined: Jan 2014
	
Thanks: 2
	Given 75 thank(s) in 62 post(s)
	 
	
	
		I'll look into it tomorrow. The work I'm currently doing has got stalled in design issues.
	
	
	
	
	
 
 
	
	
	
		
	Posts: 783
	Threads: 12
	Joined: Jan 2014
	
Thanks: 2
	Given 75 thank(s) in 62 post(s)
	 
	
	
		I'm just worried about the future impact of a command line like mcserver -s=20 -p=25565 --portv4=none --portv6=none --plugin-port-whitelist=none --ip=127.0.0.1 --ipv4=none --ipv6=none  --plugin-address-whitelist
Have you seen what  the build calls to compiler in an MCServer build are like? That's what a call to MCServer would be like to lock it down.