It can be done by using chroot in server dir. Some startup script
modification is required, but its simple.
regards
KN
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
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
