Its not fine :-D There are much more problems, which come out when the permissions aren't correct. Maybe running servers own with one user is ok. For providers it will make sense to create for every customer/server one user. I know there are some provider who handle it with a single user. It isn't easy to tell a big old script, which have 1000 of functions to work with users after a little code change. So they cant change it without spend much time for coding.
2011/1/21 Saul Rennison <saul.renni...@gmail.com>: > 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 > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
