PenUltima Online

No, this is not a "Help Wanted" sign for people to apply for positions on my staff. Though I am always open to hear from people interested.

This is more of a general question about script security etc. when bringing new scripters on to a project. How do those of you with teams of people who need access to some or all of your source/data/cfg files determine whether someone is a good risk to place them in such a position? How do you maintain security of sensitive files in the shard directory and still allow access to the files that your development team needs to work with?

First, is a very big issue of trust, with me. Under NO circumstances at all would I accept someone to be a scripter who has not already been a staff member on my shard for some time, and who has shown that they are completely trustworthy, and have the proper aptitude. In turn, I also do not accept ANY staff members who have not been players for a long time, and who did not show aptitude and trustworthiness as a player. Finally, I don't bring people on as staff (and, therefore, scripter) if they've ever asked to do it. To me, the best candidates for staff and scripters are people who have the abilities and creativeness, but who really don't want to do it... people who have to be talked into it by having it explained to them what cool things they could accomplish, over and above what they already do as players.

I know your question was not about picking staff members, but to me, a scripter is simply something of a specialized staff member, that in some ways, has higher access. So, just as I would never accept a player 'off the street' to be a staff member, I would also never accept anyone 'off the street' to be a scripter, either. I think this is something that lots of shard admins really go wrong on, with both staff and scripters, so I'm taking a lot of time to go into it; but I think trust takes time to earn, and I think it's only valid to earn it when they don't know they are 'acting' for an evaluation to come in the future. So, for us; every person we've ever asked to be staff or to help with scripting, it is always someone who never breathed a word of it themselves.



Once you do decide to give someone some access to work on scripting and such, there are a couple of what I feel are 100% iron-clad rules, and then there are some 'steps' as far as how to let them in to things.


Rules rules rules!

Don't give them access to the operating system. Ever. Do not give them the ability to have a full, interactive login on the server. Whatever operating system you are using, you can carefully assign them their own, unique user login, and then give that login only the exact rights they need to do their job. In fact, I recommend that you actually have that be nothing at all. That is, I recommend your scripters do not have ANY direct access to your server at all, but instead, you give them the files that need separately, and they send you their completed work. Personally, I have never gone beyond that level of access with anyone.

But if you do choose to give them some direct access, (or, for deciding what information you should send them...) here are some guidelines about what they should not have access to.

They should not have any rights to overwrite executable files. They don't need to be touching the pol, uoconvert or ecompile binaries. Perhaps they can have execute-only privs on uoconvert or ecompile, assuming you've decided to give them that level of access, but they should never have write permissions to it. No matter what operating system you are on, it's elementary to limit access to files (specific, or a whole directory) based on users.

They should never have even read-only rights to the data directory. Whether by accident, ignorance or purpose, they can really - pardon my language - but screw your shard with such access. Even with read-only access; You may think that because you don't store passwords in the account file, for instance, that you have nothing to fear there. But most people use trivial passwords for their account, and while no one is going to be able to figure out the password from the hash info, they can do something much easier: take a hacking dictionary, and apply the hashing algorithm to it. For example, take the word 'password', hash it using the same algorithm that POL uses, and see if it matches anyone's password in the accounts.txt file. There are programs that are easy to get and use that automate this process.

If you have a dev-type person that TRULY needs the real data from the shard, here's one possible solution: alter ALL of the account entries (via a Perl script or some other program) to have all the same old-style, plain text passwords, and remove all of the hash entries. POL -should- convert all the 'new' passwords into hashes, making them all the same thing, so your dev can test with that data, but will never know the real passwords. I've never had to do this, though, and it's best if it can be avoided.



I think you also have to look at the security perhaps not only with an eye toward purposeful harm, but accidental or ignorant harm. If you give someone direct access to the shard files, and ability to compile scripts, maybe they are perfectly trustworthy - but maybe they aren't aware of some quirk of eScript or POL itself, and maybe they implement a script without your knowledge that crashes the shard, locks it up, or corrupts some long-standing custom system you have. I have one person that does scripting, and a number of people that have altered scripts and worked on configuration issues over a long span of time. I trust all of those people entirely. However, it's not their shard; it's mine. Ultimately, I'm the one responsible for everything that gets put in. Call me a control freak (I do!), but that means I never put any file onto my production shard until I've vetted it myself.

In this, I go back to something I mentioned right at the start: time is an important factor here. The more time you see someone's scripting work (talking months and years here - not days and weeks), the more you can trust their work to meet your standards of quality. And the more time goes on where you don't see these people pulling little drama queen stunts when they don't think you are looking, stabbing others behind the back, or doing other things that should be very clear indicators that they are not to be trusted, well; the more you can trust them.

But it takes time - real time - and a willingness to understand and believe that if someone does something to someone else, they'll do it to you, as well. The fact that they say or seem to have justification for what they did to someone else just means, well... it means that everyone else will also be convinced that when they abuse your trust, they also had a good reason for it.


So.. umm... yeah

Thanks Marilla. I was counting on you to reply.
*grins*

I agree with not putting someone on who asks. I have always preferred to pull from players for staff and yes I agree that anyone who scripts, has a command level or has special access on message boards (ie. moderator etc) is a staff member.

One issue with pulling players is it can be tough when a shard is in development. If a shard is in development players are hard to come by. I suppose that's a whole new topic; How to attract players as beta testers.

I was curious about how much of your scriptset do you make available to your scripters? It stands to reason that a scripter needs to have access to some of the scripts in order to write packages and such. Since I am basically using a converted POL 095 scriptset with mods and some cleanup done by myself I had considered creating a "bare" set of scripts without any of my custom items/scripts. I'd make this available to scrupters. Thus keeping my custom shard items/scripts relatively secure.

As a side note I want to thank the POLitburo for creating this forum. We have needed a general discussion forum for a long time to address topics such as this.

I think you asked that in the first post, and I just did not get around to commenting on it. D'oh!

That's probably the most difficult issue. My main scripter gets basically the entire shard's files; I have a little prog that copies the directory structure and .src, .inc and .cfg files in them, and zips them up to send. He's the only one with access to that; not because I trust any one else less (and I don't), but just because he's the only one who works on a broad enough range of stuff to make it needed for him to have that access.

Generally, I send people only the exact files they need to work on. Due to includes, it's not always easy to do when it's scripts they may be working on.

If I had more people working more regularly on things, I think I would have to work out a system where they would be working on specific packages or groups of packages. I would alter my little snarfing/zipping program to enable me to specify which dirs they should get, and then add in any includes that might be specific to what they need to do. (I try to keep most of my includes in packages, so in many cases for me, I might be able to get away with sending them only a couple includes in addition to the package(s)).

It can definitely be a pain to 'limit' access in this way, but I think it can serve other purposes; It keeps you more 'hands on' for a while, by simple necessity. It can keep them from a desire to wander to projects maybe you didn't really want them fussing with, just yet.

As they do more for you, and you know that they are competent and trustworthy, you'll also get more tired of being so picking about what they have access to. Oh... also, side note; One thing you could do to make access a bit easier than the quasi-manual zipping I do is to give them read-only FTP Access with their own user account, and be sure to limit them only to files they are meant to see. Give them rights to directories they need access to (only for reading), and if any of those files have private info or files you don't want them to have access to, specifically deny it.


Another option you could try; If I recall correctly, the first couple things that the scripter I have now did were completely stand-alone. That's a good way to start to get an idea if they have any clue what they are doing

As I am lothe to setup an FTP server on my POL server to keep running processes at a minimum, it's an older machine and slower, I probably will stick with manual processing of script sources for now.

I appreciate the input. I like the idea of having new scripters write standalone projects. It does make it easier to test their abilities abd that way you'll get an idea of their commitment to the shard.

*nods* I don't like running anything at all extra on mine, either. If you by any chance already have IIS running on any machine that is behind the firewall, you could use that. If IIS is already running a web site, adding the FTP Service really isn't much extra at all.

For my own access to my production shard, I have a firewall and VPN, and then a private FTP server behind them. Though it's on a different server on the network, I do ALL my file access (web, DB and game servers) through that single FTP service, run by IIS. I just have virtual FTP directories set up from the FTP server to the appropriate locations on the other systems, as needed. So none of the other servers need to have FTP running (one has a public FTP server for people that have fan sites we host, but that's it).

On Linux, if you are running Samba, you could do the same from another server with FTP. There are, however, some fairly lean and mean FTP servers you could get for Linux... but still.. sometimes you just really want nothing else running.. and doing it manually isn't that bad, really, anyway; It makes sure you know exactly what goes out.


Another thing that can be a pain is getting FTP through the firewall; Since FTP takes two connections, and only the control connection is on TCP/21; Active FTP is pretty much out of the question any more with widespread use of NAT Routers and incoming-software firewalls like the Windows firewall, but Passive FTP just puts the burden back on the server to have a dynamic, open port coming back in. For our public FTP server, we have a mod to our iptables stuff on the firewall server that handles dynamically opening the required data connection back in, but it has to be configured specifically for the matching control port (it comes by default set up to work with TCP/21)... depending on where your game server is hosted, TCP/21 might not be available anyway; But anywho.. umm... I'm rambling. Imagine that!

I host my game server on a Broadband connecttion ATM. I run Apache webserver running. I use an old version of PC Anywhere (PCA) for remote access to the server. The PCA ports are blocked on the router so no outside access there. I only have the necessary ports open to log in to the server and to access the webserver though for some reason now that isn't accessable. I use PCA because it allows remote operation. That way I don't need a monitor on the server. I needed the one on the server for another computer.

*laughs*

Nothing like not having the money for a monitor.

I really can't see any reason why anyone but me would need FTP access as of yet. I know if I add a trusted scripter then that will no doubt change but even then there'd be no way for him/her to restart the shard without some remote access to the computer.

What is the server running on? If its XP Pro, try the built in Remote Desktop. It worked very well for my shard.

If it is Windows based, set up actual accounts per individual to be able to restart shard etc, but NOT have access to the data directory, and only script areas you want them to have access to, etc etc. Works nicely. Then, as CWO said, use the built in Remote Desktop ability

Something to consider for remote management - but ONLY when you have (as you do) a secure access (in my case, a VPN - in your case, you are behind the firewall anyway, so your admin traffic does not go outside of the firewall)... it's MUCH lighter on both client and server, is free, and is being actively developed;

TightVNC: http://www.tightvnc.com/
It's based on the old AT&T Labs VNC. There are other flavors of VNC available, as well, but I find TightVNC to be, well, the tightest

It's a really simple desktop; you set it up as a service on Windows (it will require WinNT/2K/XP/2K3 to do so), and set up a password for it. You then make sure the VNC service is running.

Then you can log in to it via the TightVNC client program. There's also a Java client that is automatically hosted by the server as well, to simply log in via any web browser by pointing to http://server-ip:5900/ I prefer to use the client, myself.

Note that VNC communications are NOT encrypted, so it's never safe to use to connect to a server where your connection travels an untrusted network; but when server and client are behind the same LAN (literally, or over a VPN), it's an excellent lightweight option to get full desktop access.

It does not provide file transfer capabilities, but again; it's made to be as bare-bones as possible, so that it's a small program. You can use File sharing to do the files. If you currently have file sharing disabled on that server, I actually think it would be much lighter load on the server to have File Sharing + VNC than to have PCA.


And finally, one more note: Often, you really don't need a full desktop, anyway. If your shard's running on a Server version of Windows, you can use the built-in Telnet service to provide a command shell. Depending on your network setup (same password/username on client machine, and the appropriate Windows login capabilities), you may or may not need to adjust the Telnet login settings via the Telnet Server applet (by default, it is configured only to accept integrated Windows logins, but it can also be set to allow you to type in your username/password at the standard prompt)

You would just then go to Start->Run and type telnet SERVER-IP-OR-NAME, and you'll be directed right to the command prompt of the server. From there, you can start/stop the POL service, run eCompile, and even edit text files if you get a terminal-capable text editor (the Dos 'EDIT' program that comes with Windows does NOT work properly over a Telnet session... you'll get the Edit program open, but you won't be able to use any of the menu commands!)

As with VNC, Telnet should ONLY be used over a trusted network, as it, too, sends all info unencrypted. But Telnet alone, if available, should be able to handle almost all of your server-side work for POL. The Telnet service also has a very tiny footprint memory/CPU wise.



Err... of course, if you are not running on a Server operating system, ignore everything I just said Win9X, Win2K Pro and WinXP do not have the Telnet service available. You would still use TightVNC and be 'lighter' than with PCA, though, provided you have at least Win2K.

It's WinXP system.

As for file sharing being enabled, I have to leave that disabled.

Never thought about the seperate accounts Maud. That would work. I do own an FTP server software I could setup. Then I should be able to accomplish the goal while keeping a secure environment.

I'd would recommend accounts with machine specific permissions. Goes a long way for keeping noses where they belong

Isn't that what I was saying from the beginning? Give them each their own accounts, and assign appropriate permissions...

If you have XP Home, it's a bit complex to do this - you need to be in safe mode or use the cacls command-line utility to assign permissions. XP Home hides the 'Security' tab on the properties window of files and folders unless you are in Safe Mode. Alternatively, I have a program I wrote that produces the 'Security' tab on Windows XP Home, even while not in safe mode. Unlike some other 'hacks' to get around that limitation of XP Home, my program actually produces the real XP Security tab (the one you would get if you were in Safe Mode), and not bolts on the Windows NT or 2K security tab on top of XP.

If you have XP Pro, no worries - the security tab will be there by default. But definitely be sure to set permissions - by default, XP gives some pretty wide-open file permissions, and many third-party Windows FTP servers have directory traversal bugs that allow someone to break out of the FTP root fairly easily.

Aye, Windows permissions set properly, and same for the ftp server. Not just for that user's login, but for the program itself. Keep them only where they need to be.

Sorry Marilla. Yes you did recommend specific logins/privilidges for each user.

All of these suggestions are good and helpful. A lot of them assume that one has a playerbase to draw from. It is much harder when one is just starting out, or starting over, with no playerbase to choose from.

Anyway, thanks again for all the input.

That does make it difficult, yes. However it also arguably makes it even more important, in a way. The choices you make now in who to bring on and how to bring them on will have a much greater effect on things overall if the shard does not have years of history behind it already. Essentially, what you do now makes your shard's history, and sets the standards by which it will be viewed for a good while.

Agreed.

The one thing I have found when I had more scripters was keeping them on task too. Seems like it's hard to get people to do what is needed. Instead it seems folks want to script what they want to rather than what is needed.

There is one last thing I realized that we hadn't discussed.

Hypothetically speaking Marilla, if I were one of your players and you had decided to entrust me with a postion as a scripter and assuming I had proven my capabilities, how would you convince me that working for you is better than doing my own thing and starting my own server? It's not like we can offer money (unless you are independantly wealthy ofcourse). So what kind of incentives do you offer to a prospective scripter to make them want to work for you? There has to be some payoff for them.

I dunno. I've tried FIVE times now to formulate a response to this, and I end up just rambling on and on! I'm gonna try again...

Short answer!

As a shard owner, we have literally nothing to offer people who might be staff or scripters. They must simply have a desire to 'give back' to the shard. That must be of value to them! If they do not get value simply out of helping to entertain others, things will likely go downhill quickly.

I left out, specifically, a desire to help YOU. That is: For your own good, do not bring in anyone you consider to be a 'personal friend' to help you run your shard, if it's not something they are very enthused about doing. Even if they are, I'd still be careful...


I think this is something that my own staff know is always in the back of my mind. I've certainly said it aloud to them. Hopefully none of them reading here, now, are surprised by this! But to a great extent, there is a real, palpable danger of "using" your staff. After all, there is little you can do for them beyond 'recognition'. And in our case, our shard has a rule that staff members cannot reveal who their normal player characters are, so that even sort of limits that.

If someone is thinking of being staff/scripting to 'get' something out of it, that's bad. If anyone ever comes to you and asks you the literal question you just sort of posed: "What's to make me want to script for you instead of running my own shard?" my answer is instant: "Enjoy running your own shard! kthxbai!"


I can't emphasize this enough: There is really nothing you can give them. Not only do I recommend that you have to find people that need to be talked into it; but I further say that there's nothing you can really do to make it worth their while.

They have to truly want to 'contribute' to the shard itself; They have to agree within themselves that the purpose for doing what they are doing is to enjoy entertaining others. Period. It's about the process; not the results. And another thing: They, and you, must also understand this: At some point, that process may no longer be rewarding for them. I think it's important to recognize that, and plan for it. I think it's important to maintain good and proper rules and such, as you see fit, but beyond that, don't take their 'positions' too seriously, and don't let them do so. The moment it becomes anything like 'work' to them, they should no longer be doing it, and they and you should both understand that, and plan ahead that there be a soft landing for them, to hopefully just go back to playing the shard, or perhaps even leave the shard altogether. It's just a reality that I think is important to keep in mind.


For an established shard, this is all a bit easier. When you've been playing on a shard for a couple years, and maybe, despite the regular updates and interesting new quests and such, you start to feel like you've "done it all", sometimes the offer of a staff position can be a new, invigorating and exciting challenge that can be very enjoyable, in and of itself. Not just to 'be staff' - but to be staff on that shard, with those people you've been playing with for so many months now. For people with the right mindset, being staff/scripter is itself it's own reward. But as the owner, it's important that you do all you can to help them enjoy that time; put up reasonable and good boundaries (like rules on how they can or cannot interact with players as their GMs, based on your own principles), and enforce those consistently, so that the staff always know where they stand. Make it clear to them that you want them to enjoy their time, and also make it clear to them that should they ever NOT enjoy it, you want them to talk to you about it, and whatever the result needs to be, it will be.


And that's all probably a bit more difficult for a younger shard to do; People often jump at the chance to do this sort of thing for a shard they've been enjoying for years, and they get so much more out of it as they do it, prolonging the time during which they will enjoy it. But for a new shard, that's real tough. People are not going to be very likely to want to put time and effort in ahead of time when the shard itself is an unknown quantity - they may only do it for YOU, because they are your friend, and believe in you. But that puts you in what I think is a messy situation where they believe they are doing you a favor. They don't feel like they are doing it because they enjoy it - but it is a show to you of their friendship, and people always expect such displays to be repaid somehow. And then, far more common, are the people who will want to do it because they think they'll 'get' something out of it.


==============

It occurs to me that maybe I'm coming across a bit.. well.. misogynistic. I hope that the staff we have on our shard would defend me on that point! But I think it's important to understand what people want and expect, and never to get into a situation where someone is doing something for you, but where they won't get what they expect back. I think it's important to try to understand what they really want, and then to realistically consider; can you provide that to them? My answer, arrived at after much gnashing of teeth, let me tell you, is that there is nothing *I* can offer them - they must want to do it merely for the joy it offers itself.

I have come to the same conclusion over the years I have been scripting/operating various incarnations of my server. I just wondered if I was missing something. I thought maybe I needed a new perspective.

I once wrote on the "Advertise UO" boards that we, the developers, must never forget the reason we do what we do; because we enjoy it. If we lose the joy we need to re-evaluate why we are still running a server. I suppose the same applies to staff.

Obviously being a free server I cannot pay them. So the financial aspect is not a factor. If I were to offer them aid in starting their own server I would be defeating my purpose in having them aboard. Outside of those two things and ofcourse the one you mentioned, friends helping me because they are friends, I can see no logical reason why anyone would help a developer except for the enjoyment of the process.

That reason in itself might seem rather sad to most on the surface but in reality isn't that why we do the things we do? Because we enjoy them?

I truly appreciate your input Marilla. You caused me to re-discover the reason I do what I do and so to understand that my staff must also do what they do for that reason and no other. Perhaps it's time that we, both myself and my staff, examine whether we still enjoy what we do.

Once again, thanks to the POLitburo for this "General Discussion" forum.

I've always done it, as I do it, because I enjoy it. Not just as a core developer, or shard admin, or shard developer, but as a Player. I enjoy the game itself, the reaction from others who enjoy the game, and those who are learning it. I have never done any of this, out of enjoyment of the scripting or coding or working on it for players, but for the reasons I play it myself, enjoy the game, enjoy the reaction the players give back. You must love it not as a developer, but as a Player. As a player, through those eyes, you create something more powerful than a mere game. You create bonds, friendships, enemies and allies. Throw the politics to the wind and create as you would love, for your love will show through to those who also enjoy it.

This is also where the decisions of who to let do what come in. Protect your love as you would an infant. And remember, everyone needs a vacation. You take vacations at work, etc, it's the same here. Do what you enjoy, but know when to take a vacation to keep that enjoyment strong.

Very well said Maud Dib.