DLL Calling Safe Mode Default

ID:96110
 
May 29 2010, 10:04 am
Applies to:DM Language
Status: Open
Issue hasn't been assigned a status value.
In a kind of compromise to http://www.byond.com/members/ DreamMakers?command=view_tracker_issue&tracker_issue=1052 I think it would at least make DLL calling usable if you could call DLLs by default in safe mode if the DLL is located in the same directory as the DMB. This improves the deployment scenario for DLLs, making them actually viable for games that are distributed to an arbitrary number of hosts. Libraries still have a pretty big issue using DLLs in that the conventional library model in DM assumes no resources need bundling with the DMB, so developers have to copy across. Another feature could be implemented to help that, but is outside the scoep of this request.

Consider the following DLL. It essentially just provides file reading capabilities similar to file2text(), however with much better through-put and line-wise.

http://www.byond.com/members/Stephen001/files/O.rar

For a lot of scenarios, file2text will perform "well enough". However once you try reading in a big text file, (450 kb for Maztekia's default.dmf) it's performance becomes untenable for some applications, taking 3.6 seconds just to read the file in. This is obviously a niche requirement, and one that can be handled by a DLL. The DLL's implementation reads in the same file in ~300 ms (would've been less but I hit a string limit on BYOND's end), making use of such a size of file tenable again.

Brilliant. However to use a shared object on Linux (arguable how you'd want to host a game with fancy features and heavy player loads), you either need to go through the install process for BYOND to let you use the code in safe mode, or run in trusted mode. If DLL calling was safe mode by default, such a DLL could be in more general purpose use without having to compromise an let BYOND worlds potentially make shell() calls etc.

I'm not sure what ATP's security requirements are for hosting, but I assume they require the world is ran in safe mode.
May 29 2010, 10:27 am
Another viable alternative for the particular case is improve file2text. I dunno what you're doing, but it should not be 18x slower than the following:

std::fstream input( name.c_str() );
input << std::noskipws;
std::istream_iterator<char> inIt( input ), eof;
data = new std::string( inIt, eof );

It's all standard C++. I'm sure there are a few exceptional cases, but even handling them can't make it 18x slower, surely?
Jun 4 2010, 8:46 pm
The reason safe mode works is that we can guarantee that nothing outside of that directory will be touched and as such the host's machine will not be compromised. Since this is the default runstate of dmbs, it is pretty important that it is secure. If we used your metric, anyone could make a game that thrashed a hard drive (say) and distribute it in BYOND, and when a user downloaded and ran it (in safe mode, by default).. well, that wouldn't look so good for us.

In windows I don't think this is such an issue because we implemented your suggestion a while ago to prompt users for DLL approval at host startup. However, for linux this is not an option and I see where you are running into problems (since outside hosts most likely aren't allowing -trusted). So perhaps we need another flag that those hosts could use. Of course, I'm not sure what would convince them that the DLLs are safe.

Really, I think what we need is a way of universally validating DLLS intended for distribution so that we wouldn't have to go through any of this nonsense. Having the source be present and compiled by a trusted party (or even ourselves) would be enough. We'd then have to provide a way of communicating this security stamp (easy through the hub, if we have that).

I understand your frustration with this but as long as we are distributing games through our site, we have to be paranoid. It only takes one bad seed.

As far as the file2text issue, that is odd. Our routine just uses fread() to grab the data (which has to be what the C++ calls eventually). We'll have to run some diagnostics to see what's going on here.
Jul 16 2010, 7:35 am
Tom wrote:
As far as the file2text issue, that is odd. Our routine just uses fread() to grab the data (which has to be what the C++ calls eventually). We'll have to run some diagnostics to see what's going on here.

The C++ iostream will actually usually call onto OS specific ioctls, as opposed to fread. At a guess you're reading with some fixed buffer size via that mechanism. The benefit of something like the istream_iterator is that it has template specialised implementations for things like char, usually picking a buffer that much better suits the underlying stream (in my case a stream with noskipws applied).

I can probably provide similar non-STL implementations, but then you're getting into awkward platform specific calls that STL is designed to shield you from.
Jul 8 2011, 4:10 pm