I thought of the rcon issue previously but I forgot to bring it up. Massive problem that some people on this list thing that all customers on one user is fine.
On Friday, 21 January 2011, Joonas Lehtolahti <joonas.lehtola...@lehtopuu.fi> wrote: > The point isn't really that plugins can be loaded from elsewhere. No, that > isn't needed, but the real problem is bigger than that. The srcds process has > as much access as the user/group it is running as. If a user can upload a > plugin to be used on that server, that plugin also has all the privileges as > the host srcds process has. That is, it can go for example check the > rcon_password variables from config files of other customers' installations > if they are installed with the same user account. That as a simple example. > If a customer should not be able to access the files of other customer, then > their processes must be run with different local user accounts. > > > On Fri, 21 Jan 2011 18:48:18 +0200, Andre Müller <gbs.dead...@googlemail.com> > wrote: > > > You all think it's ok, when the server can load plugins from anywhere. > Do you need this? Tell me why. > > In example one provider have one user for all gameservers on a host. > Every customer gets chrooted FTP-Access (virtual users) to his own > serverdirectory. So he/she can't access to the other directories. I > know you like it more complex and want for everey gameserver his own > user. Nice, safty first. > Then is the next problem to get the screen for an different user to > his gameserver for debuging. Maybe sourcemod hangs or something else. > > When you like hacks, you can execute as root: > > chmod 666 `tty`; su -c "screen -r css_27015" customer123 > > A little nice hack. I know you can use shared screen sessions. You > like more complexity. > > Third example: You are using Teklab and your customer have two > gameservers. So the customer can access to his two gameservers, when > they are on the same host. In this situation the customer can load > plugins from his second gameserver. There are many mini hosters who > uses this. > > You really want to tell me, that you ever have loaded Plugins from > outside the serverdirectory? > plugin_load "/home/plugins/zBlock/zblock" > I don't have tested it until yet, where the server after this writes > the logfiles for zblock. Maybe in your addons-directory or outside in > /home/plugins/zBlock/zb_logs/? > > I think its easier and safer to use for this way symlinks. The safest > way is, to block only loading plugins, which aren't located in servers > directory, but don't break the support for symlinks ;-) > > 2011/1/21 Marco Padovan <evolutioncr...@gmail.com>: > > Agree to this :| > > Why can a single user access to another customer dir? > I can understand maybe to /tmp or things like that... but another customer > dir?? :/ > > Il 21/01/2011 09:40, Marcel ha scritto: > > > If the provider really allows access to other customer directories he > should stop renting servers and do his homework first. > This is really no job for Valve. > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > -- Thanks, - Saul. _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
