Page 3 of 3

Posted: Thu Jul 27, 2006 5:14 am
by [FL]Blindman
I think this would work very well in multiple instances of the game, just sticking it in the users home directory. Also works in webmin as a custom command and init as well.

Posted: Thu Jul 27, 2006 7:25 am
by deej
Mr.Mxyzptlk wrote:The script does not change the UID or EUID of the calling user, it only identifies the EUID of the calling
process and uses it to limit pgrep scope.
In other words, don't run it as root but chown it to the user you wish it to be run as? Or use su -c <script> <user_to_run_script_as> if you desperately want to start it when logged in as root. Correct?

Posted: Thu Jul 27, 2006 8:27 am
by [FL]Blindman
wouldnt it default to whoever was calling it without all the su stuff? I dont personally log in from anywhere but my own lan so most of this is moot. I dont run telnet and ssh ports arent even open to the outside. So if theres an exploit found at some point, yer saying by running it as anyone but a nolgin user is a possible threat?

Posted: Thu Jul 27, 2006 9:58 am
by deej
[FL]Blindman wrote:wouldnt it default to whoever was calling it without all the su stuff? I dont personally log in from anywhere but my own lan so most of this is moot. I dont run telnet and ssh ports arent even open to the outside. So if theres an exploit found at some point, yer saying by running it as anyone but a nolgin user is a possible threat?
If the service you run as "root" is comprosimed it gives "root" access. So yes, it's a threat. Not a very big one, but still a threat. The necessary patch of 2.60b proved that. Running it as a non-privileged user that can't login & is in its own group is about as far as you can go on a user level. You could take it even further and go chroot the gameserver or even further: create a virtual machine with Xen (or VMWare if you have the $$$) and run your gameserver in there.

If you think I'm nuts you're right, I'm a security professional in real life, that explains my paranoia ;-).

Posted: Thu Jul 27, 2006 11:45 am
by Mr.Mxyzptlk
deej wrote:
Mr.Mxyzptlk wrote:The script does not change the UID or EUID of the calling user, it only identifies the EUID of the calling
process and uses it to limit pgrep scope.
In other words, don't run it as root but chown it to the user you wish it to be run as? Or use su -c <script> <user_to_run_script_as> if you desperately want to start it when logged in as root. Correct?
Correct, the caller has the responsibility being or becoming the correct UID.

I'll think about putting in an optional setting which would guard against starts by an incorrect user, and/or perform a convenient su
if run as root (ie: from system startup as if placed in /etc/init.d structure). That might help a lot of people.

Posted: Thu Jul 27, 2006 3:16 pm
by deej
Mr.Mxyzptlk wrote:I'll think about putting in an optional setting which would guard against starts by an incorrect user, and/or perform a convenient su
if run as root (ie: from system startup as if placed in /etc/init.d structure). That might help a lot of people.
That sounds like a very good plan. People will often forget to chown the script or the entire directory. Looking forward to your next version!

Posted: Fri Jul 28, 2006 9:26 am
by [FL]Blindman
this is a little off, but related I think---
I set up a server on a usb drive and when I do serverctl start I get this----

Code: Select all

/mnt/usbflash/et//serverctl: line 155: log/2006.07.28-10:23:10: Invalid argument

Posted: Fri Jul 28, 2006 9:31 am
by Mr.Mxyzptlk
deej wrote:
Mr.Mxyzptlk wrote:I'll think about putting in an optional setting which would guard against starts by an incorrect user, and/or perform a convenient su
if run as root (ie: from system startup as if placed in /etc/init.d structure). That might help a lot of people.
That sounds like a very good plan. People will often forget to chown the script or the entire directory. Looking forward to your next version!
Script has been updated (edited the same post).
It now includes a mode that if you set the ET_ACCOUNT var, it will only work when executed by that user -- safety guard.
Also a special for root. If ET_SUDO_ENABLE=1, the root may run the script and the script will use sudo (expects it to be installed),
to re-execute the script as the account named in ET_ACCOUNT. sudo was used INSTEAD of 'su' utility because su has severe
limitations in working when the account doesn't have a normal user shell. ie: I wanted it to work even if the account has /sbin/nologin as
the shell.

Posted: Fri Jul 28, 2006 9:33 am
by Mr.Mxyzptlk
[FL]Blindman wrote:this is a little off, but related I think---
I set up a server on a usb drive and when I do serverctl start I get this----

Code: Select all

/mnt/usbflash/et//serverctl: line 155: log/2006.07.28-10:23:10: Invalid argument
It looks like you've edited some other parts of the script.
...forgot a line continuation in server_loop() function?
Compare it very closely to the original script.

Posted: Fri Jul 28, 2006 5:26 pm
by [FL]Blindman
NP, had to do with the pre installed vfat file system on the usb drive. Works fine now thats its ext2fs.

Posted: Sun Jul 30, 2006 3:38 pm
by deej
Mr.Mxyzptlk wrote:I wanted it to work even if the account has /sbin/nologin as
the shell.
That's what the -m parameter does for su.

su gamed -m -c etded.x86 will run etded as gamed while gamed has /sbin/nologin as shell.

Posted: Sun Jul 30, 2006 4:07 pm
by Mr.Mxyzptlk
deej wrote:
Mr.Mxyzptlk wrote:I wanted it to work even if the account has /sbin/nologin as
the shell.
That's what the -m parameter does for su.

su gamed -m -c etded.x86 will run etded as gamed while gamed has /sbin/nologin as shell.
Ah good. I'll switch to using this instead, it's more likely to work out of the box:
su -m "$ET_ACCOUNT" -c "$ET_HOME/$LOOPER_BASENAME $@" || exit 1