- file::DeleteFile(filename);
For safety reasons you should limit it so the function can only delete files within the pol directory and it's subdirectories. There should also be a new entry in fileaccess.cfg for "AllowDelete 0|1" (default of 0). - cfgfile::DeleteConfigElem(ConfigFileRef, ElementKey);
Function requests: 'DeleteFile()' and 'DeleteConfigElem()'
Moderator: POL Developer
-
- Grandmaster Poster
- Posts: 104
- Joined: Tue Feb 07, 2006 3:32 pm
- Location: Pittsburgh, Pennsylvania
Function requests: 'DeleteFile()' and 'DeleteConfigElem()'
Two functions I would like to see implemented are:
I'd actually like to see a full 'shell' ability, myself, without any checks done by the core for permissions at all. (since, IMO, permissions should be handled by the OS, not by POL; one simply needs to run POL under a user account that has only the permissions desired. In this day-and-age of Buffer Overflows, I already do that with my POL - run it under a limited account with only the barest of permissions needed.)... err... anywho, of course that would possibly include the ability to delete files through the OS's delete abilities, though perhaps a DeleteFile() function in the file module would be separately useful, too.
As for the config thing, though; I suspect that the reason config element access is so fast in POL is in large part due to the fact that you cannot modify or delete entries, but only add and read. If you need read/write access to the entries, the DataFile em offers all the functionality you might need (except to delete an entire file, which is covered by the above).
This way, we can keep the ultra-fast access of config files, while also still having the ability we already have to create a more dynamic store, with the datafiles.
As for the config thing, though; I suspect that the reason config element access is so fast in POL is in large part due to the fact that you cannot modify or delete entries, but only add and read. If you need read/write access to the entries, the DataFile em offers all the functionality you might need (except to delete an entire file, which is covered by the above).
This way, we can keep the ultra-fast access of config files, while also still having the ability we already have to create a more dynamic store, with the datafiles.
-
- Distro Developer
- Posts: 2825
- Joined: Thu Feb 02, 2006 1:41 pm
- Location: San Antonio, Texas
- Contact:
Marilla,
Here is one reason I can see DeleteConfigElem(ConfigFileRef, ElementKey); added: It would be handy for deleting elements from such files as the golocs files. If I had that functionality I could remove all those unnecessary locations from the go list within the script without directly editing the file. Now I will be the first to admit that I have no idea if or how this might affect server performance. I imagine if this affects performance then the same function with datafiles would do the same.
As for the DeleteFile(filename); function, I can see the value of this. I can think of script based file manipulations that would benefit from having this feature. I could explain a scenario here but it would take a long time. I think these functions are obvious and valuable. However, I can see why the devs might keep a file delete function out of the emu for security purposes.
Here is one reason I can see DeleteConfigElem(ConfigFileRef, ElementKey); added: It would be handy for deleting elements from such files as the golocs files. If I had that functionality I could remove all those unnecessary locations from the go list within the script without directly editing the file. Now I will be the first to admit that I have no idea if or how this might affect server performance. I imagine if this affects performance then the same function with datafiles would do the same.
As for the DeleteFile(filename); function, I can see the value of this. I can think of script based file manipulations that would benefit from having this feature. I could explain a scenario here but it would take a long time. I think these functions are obvious and valuable. However, I can see why the devs might keep a file delete function out of the emu for security purposes.
Actually, as I noted in my original post, not only do I like the idea of implementing file deletion, I'd like to see it go much further, and have full shell capability. Security is handled very simply: use the OS' security features; Windows, Linux and BSD all have very robust systems already in place whereby you can easily limit what commands and files the POL process would be allowed to manipulate, call, delete or execute.
But my problem with the other request is that the functionality she's asking for already exists; she just isn't using the proper system. As a result, instead of fixing her scripting to use the appropriate system (DataFiles instead of Config files), she's asking for features to be added to a system that is meant for completely different kinds of use.
If you want to implement your 'goloc' system and permit items to be deleted or edited, then use DataFiles. DataFiles are -perfect- for that sort of thing.
Of course, I'm not developing POL myself, but I can easily guess how this might all be implemented. Devs in the past have been very clear: The config file system is implemented for optimized speed of access to elements, and the data within them. This is why we can have CombatHook scripts that have the entire :*:itemdesc and :*:npcdesc config file system loaded and 'instantly' access NPC and weapon elements, in the highest priority scripts that exist.
It basically has to do with how the memory is allocated and indexed for those files. When you allow 'dynamic' moving and editing of information in memory, it means access to those things will be slower. A 'simple' act of modifying a single string entry, or deleting an entry, could require shuffling of large parts of the buffer holding all that data. That, in and of itself, will take time, during which the data would not be accessible to anything, as would altering the 'index' pointing to the specific records. Whereas the current system simply loads the info from the files up, and the only functionality built in 'dynamically' is to tack new records on, and that doesn't require any modification of existing items at all.
So basically, because someone doesn't feel like using the proper method to do something (Data files instead of config files), they are asking for changes that while it wouldn't make ANY noticeable difference in, say, the speed of finding your .golocs, it would certainly make a difference in the speed of finding NPC and Item information loaded from the config files.
But my problem with the other request is that the functionality she's asking for already exists; she just isn't using the proper system. As a result, instead of fixing her scripting to use the appropriate system (DataFiles instead of Config files), she's asking for features to be added to a system that is meant for completely different kinds of use.
If you want to implement your 'goloc' system and permit items to be deleted or edited, then use DataFiles. DataFiles are -perfect- for that sort of thing.
Of course, I'm not developing POL myself, but I can easily guess how this might all be implemented. Devs in the past have been very clear: The config file system is implemented for optimized speed of access to elements, and the data within them. This is why we can have CombatHook scripts that have the entire :*:itemdesc and :*:npcdesc config file system loaded and 'instantly' access NPC and weapon elements, in the highest priority scripts that exist.
It basically has to do with how the memory is allocated and indexed for those files. When you allow 'dynamic' moving and editing of information in memory, it means access to those things will be slower. A 'simple' act of modifying a single string entry, or deleting an entry, could require shuffling of large parts of the buffer holding all that data. That, in and of itself, will take time, during which the data would not be accessible to anything, as would altering the 'index' pointing to the specific records. Whereas the current system simply loads the info from the files up, and the only functionality built in 'dynamically' is to tack new records on, and that doesn't require any modification of existing items at all.
So basically, because someone doesn't feel like using the proper method to do something (Data files instead of config files), they are asking for changes that while it wouldn't make ANY noticeable difference in, say, the speed of finding your .golocs, it would certainly make a difference in the speed of finding NPC and Item information loaded from the config files.
-
- Distro Developer
- Posts: 2825
- Joined: Thu Feb 02, 2006 1:41 pm
- Location: San Antonio, Texas
- Contact:
I am sorry but I fail to see how allowing the deletion of an entire entry in a cfg file might slow down overall access to cfg files. Afterall you'd only be removing the entry from one file. Now understand I am not talking about removing one piece of data from within an entry. It would be removing the entire entry (everything between the '{}' and the keyname preceeding the '{}').
However, I do see a problem with allowing the deletion of entries from critical cfg files such as NPC and Item description files. So in light of that I can see where a scripter could wreak havoc if she or he were not careful in using this function.
But I also see your point with data files as alternatives for cfg files. I do find it interesting however that the Distro uses cfg files for its makeset and golocs data storage. I am curious why they chose to do that if datafiles are just as good as cfg files. Maybe a distro dev could comment on this.
However, I do see a problem with allowing the deletion of entries from critical cfg files such as NPC and Item description files. So in light of that I can see where a scripter could wreak havoc if she or he were not careful in using this function.
But I also see your point with data files as alternatives for cfg files. I do find it interesting however that the Distro uses cfg files for its makeset and golocs data storage. I am curious why they chose to do that if datafiles are just as good as cfg files. Maybe a distro dev could comment on this.
I'll try to explain. Please note this is only going off some assumptions about how config data is accessed; the real system could vary on many details, though the principles will apply. I'm also simplifying the explanation as much as possible.
The first thing I should note is this: ANY sort of file access at all takes time. As far as POL is concerned, file access is about the slowest thing there is. When POL needs to read a config file, it reads the whole file to a memory buffer, then it ignores the config file from then on out. This is why changes to a config file have no effect unless you unload the config data. When you unload the config data through scripts, the next access is going to take a relatively long time because of it, because the file has to be read into memory again.
So basically, under normal use, POL isn't reading data from the file at all. It's storing it in memory, because reading the info from a file would take a very long time. Imagine if POL had to access the itemdesc FILE every single time you took a swing with a weapon; POL would be completely unplayable.
Saving new entries is obviously a slight exception, however, it's still done in an optimized way; The new entry is simply 'tacked on' to the memory buffer, and then appended to the file. That takes time, yes, but not a lot; Because appending data to a file is considerably faster than seeking and modifying information in a file... such as doing the 'simple' act of parsing a file to find a certain entry, and then removing that entry.
Actually, to do that, POL would need to re-load that file into memory, or read it from a stream. It would have to remove the deleted part, and then re-save the whole new file. That might seem 'simple', but when you are looking for the utmost performance, it's not at all 'simple'; disk access is time consuming.
Simply appending new text onto the end of a text file, though, is a relatively fast operation as far as disk operations go. The file doesn't need to be read into a buffer or streamed at all; the new data can simply be tacked on to the end, much like the new data was already tacked on to the end of the in-memory buffer, too. (note that when you add a new entry, POL still isn't -reading- the config file. It already has the info from the config file in memory, and it's adding just your new entry to it's memory, and then in a slightly lower-priority thread, saving the new data. This way, the impact on performance is almost nonexistent.
------------
But even beyond how this system precludes the need for file access methods that take unacceptably long, this system also improves just how the memory buffer itself works.
As I noted, POL likely never reads config file values straight from the file; The file's info is loaded and parsed on the first access, and stored in memory. The important data is then accessed straight from memory. Certainly, you don't think POL is seeking in all the various npcdesc.cfg files to look for the monster's config between the squiggly brackets each time a monster swings in melee combat? No, of course not; it's loading it's information from a memory buffer.
But just as the file access is much quicker when it's only streamed in once, and from then on, only 'appended' to, and never edited, access to the config data in memory is also faster when the only operations permitted are reading and appending to the end.
For example, imagine a 'simple' array of integers, 200 items long. POL has to reserve a region of memory into which that information can be stored. Because this is simple scalar values in a simple array, indexing isn't even an issue here; simple pointer arithematic almost instantly accesses any value. However, what happens if you want to 'simply' remove the first entry from the array? Well, turns out it's not so simple; To continue to operate properly, unless you want that first item to now hold an 'invalid' (null) value, you must now 'collapse' that array, by moving each item down one slot. In fact, in eScript, when you 'remove' an item from an array, POL must do this 'collapsing'. As the scripter, you don't worry about it - you just refer to the next ArrayVar[1]; item without knowing what POL had to do in the background, but in reality, POL needed to do a good bit of work to 'simply' remove one item.
As I noted above, that was just a simple one-dimensional array storing scalar values. The trouble can become much greater when you are talking about what is likely stored as a 'dictionary' or 'collection' of some sort, that has an index that it needs to keep up. Let's just say, for sake of argument, that POL stores the config data in something similar to a 'dictionary'; Where you have a 'key' to find an item, and then the value.
"Great!", you might say... "It's easy, then! It's easy to delete an item from a dictionary." Well; when you are presented with a scripting interface to a dictionary object, sure, it's easy. But a dictionary actually has a lot of code behind the scenes that maintains relationships between the keys and the values.
I've never written a dictionary class of any sort myself (why, when the STL and the .NET Framework are full of ready-made stuff?), but the typically understood way that the simplest of dictionary type objects work is that internally, they store two separate arrays; one array being of the values, and the other being of the keys. The second array could be a two-dimensional array, with the first value being the key, on which that whole array is sorted, and the second being a pointer/offset to the actual corresponding value.
Assuming POL's config information were stored in memory in this way, it's easy to imagine how POL might populate that from the beginning, and then give access to the information when needed. Even adding new entries would not require huge amounts of 'shuffling' of memory, because only the 'index' array would need to be altered, putting the new key in the proper location (sorted properly). The actual value (which remember, for the config data, is much more information than the 'key' or ID of the element) can actually just be tacked on to the end of the 'values' array.
But to permit editing or deleting of those entries would mean that both the keys and values arrays would need to be modified. However, it's even more than that; If you add a new entry with a key that falls in the middle of the other keys when sorted, it's not a big deal; The key array has to have it's values shifted up one for the entries that are now 'after' the new entry, but the actual values of the items in that key array do not need to be changed, because the values they point to are still in the same place.
However, if you were deleting items, not only would you have to shift many the key array entries by one, you would actually have to completely recalculate where all the pointers/offsets of those keys point to, because when you deleted a 'value' from the values array, it had to collapse to accomodate that.
And of course, during the time it's doing this 'reindexing', nothing at all can access the 'dictionary'; it must be 'locked', because any thread trying to read those values might get garbage, or an incorrect value.
The first thing I should note is this: ANY sort of file access at all takes time. As far as POL is concerned, file access is about the slowest thing there is. When POL needs to read a config file, it reads the whole file to a memory buffer, then it ignores the config file from then on out. This is why changes to a config file have no effect unless you unload the config data. When you unload the config data through scripts, the next access is going to take a relatively long time because of it, because the file has to be read into memory again.
So basically, under normal use, POL isn't reading data from the file at all. It's storing it in memory, because reading the info from a file would take a very long time. Imagine if POL had to access the itemdesc FILE every single time you took a swing with a weapon; POL would be completely unplayable.
Saving new entries is obviously a slight exception, however, it's still done in an optimized way; The new entry is simply 'tacked on' to the memory buffer, and then appended to the file. That takes time, yes, but not a lot; Because appending data to a file is considerably faster than seeking and modifying information in a file... such as doing the 'simple' act of parsing a file to find a certain entry, and then removing that entry.
Actually, to do that, POL would need to re-load that file into memory, or read it from a stream. It would have to remove the deleted part, and then re-save the whole new file. That might seem 'simple', but when you are looking for the utmost performance, it's not at all 'simple'; disk access is time consuming.
Simply appending new text onto the end of a text file, though, is a relatively fast operation as far as disk operations go. The file doesn't need to be read into a buffer or streamed at all; the new data can simply be tacked on to the end, much like the new data was already tacked on to the end of the in-memory buffer, too. (note that when you add a new entry, POL still isn't -reading- the config file. It already has the info from the config file in memory, and it's adding just your new entry to it's memory, and then in a slightly lower-priority thread, saving the new data. This way, the impact on performance is almost nonexistent.
------------
But even beyond how this system precludes the need for file access methods that take unacceptably long, this system also improves just how the memory buffer itself works.
As I noted, POL likely never reads config file values straight from the file; The file's info is loaded and parsed on the first access, and stored in memory. The important data is then accessed straight from memory. Certainly, you don't think POL is seeking in all the various npcdesc.cfg files to look for the monster's config between the squiggly brackets each time a monster swings in melee combat? No, of course not; it's loading it's information from a memory buffer.
But just as the file access is much quicker when it's only streamed in once, and from then on, only 'appended' to, and never edited, access to the config data in memory is also faster when the only operations permitted are reading and appending to the end.
For example, imagine a 'simple' array of integers, 200 items long. POL has to reserve a region of memory into which that information can be stored. Because this is simple scalar values in a simple array, indexing isn't even an issue here; simple pointer arithematic almost instantly accesses any value. However, what happens if you want to 'simply' remove the first entry from the array? Well, turns out it's not so simple; To continue to operate properly, unless you want that first item to now hold an 'invalid' (null) value, you must now 'collapse' that array, by moving each item down one slot. In fact, in eScript, when you 'remove' an item from an array, POL must do this 'collapsing'. As the scripter, you don't worry about it - you just refer to the next ArrayVar[1]; item without knowing what POL had to do in the background, but in reality, POL needed to do a good bit of work to 'simply' remove one item.
As I noted above, that was just a simple one-dimensional array storing scalar values. The trouble can become much greater when you are talking about what is likely stored as a 'dictionary' or 'collection' of some sort, that has an index that it needs to keep up. Let's just say, for sake of argument, that POL stores the config data in something similar to a 'dictionary'; Where you have a 'key' to find an item, and then the value.
"Great!", you might say... "It's easy, then! It's easy to delete an item from a dictionary." Well; when you are presented with a scripting interface to a dictionary object, sure, it's easy. But a dictionary actually has a lot of code behind the scenes that maintains relationships between the keys and the values.
I've never written a dictionary class of any sort myself (why, when the STL and the .NET Framework are full of ready-made stuff?), but the typically understood way that the simplest of dictionary type objects work is that internally, they store two separate arrays; one array being of the values, and the other being of the keys. The second array could be a two-dimensional array, with the first value being the key, on which that whole array is sorted, and the second being a pointer/offset to the actual corresponding value.
Assuming POL's config information were stored in memory in this way, it's easy to imagine how POL might populate that from the beginning, and then give access to the information when needed. Even adding new entries would not require huge amounts of 'shuffling' of memory, because only the 'index' array would need to be altered, putting the new key in the proper location (sorted properly). The actual value (which remember, for the config data, is much more information than the 'key' or ID of the element) can actually just be tacked on to the end of the 'values' array.
But to permit editing or deleting of those entries would mean that both the keys and values arrays would need to be modified. However, it's even more than that; If you add a new entry with a key that falls in the middle of the other keys when sorted, it's not a big deal; The key array has to have it's values shifted up one for the entries that are now 'after' the new entry, but the actual values of the items in that key array do not need to be changed, because the values they point to are still in the same place.
However, if you were deleting items, not only would you have to shift many the key array entries by one, you would actually have to completely recalculate where all the pointers/offsets of those keys point to, because when you deleted a 'value' from the values array, it had to collapse to accomodate that.
And of course, during the time it's doing this 'reindexing', nothing at all can access the 'dictionary'; it must be 'locked', because any thread trying to read those values might get garbage, or an incorrect value.
- MontuZ
- Forum Regular
- Posts: 338
- Joined: Fri Feb 10, 2006 8:08 am
- Location: Myrtle Beach, South Carolina
Sorry, Marilla. I didn't read all of your post.
Anyway, not trying to start an arguement, just voicing my 'idea' on how it could, if possible, work. Granted I don't know shit about how this stuff works, I'm still going to toss it out here. Maybe I'll learn something new.
Yeah, pol keeps all loaded cfg files cached(For faster access). So once loaded, the orginial cfg file is just kind of sitting there hanging out until the cached data is unloaded. We don't want to edit the cached data, we want to edit the file. So when we unload it, the new data will be recached.
Make any sense? It does to me, I don't see how this could even possibly slow down reading cfg files, elements, etc. Seeing we're not even going near the cached data.
Yeah,
Anyway, not trying to start an arguement, just voicing my 'idea' on how it could, if possible, work. Granted I don't know shit about how this stuff works, I'm still going to toss it out here. Maybe I'll learn something new.
Yeah, pol keeps all loaded cfg files cached(For faster access). So once loaded, the orginial cfg file is just kind of sitting there hanging out until the cached data is unloaded. We don't want to edit the cached data, we want to edit the file. So when we unload it, the new data will be recached.
Make any sense? It does to me, I don't see how this could even possibly slow down reading cfg files, elements, etc. Seeing we're not even going near the cached data.
Yeah,
-
- Distro Developer
- Posts: 2825
- Joined: Thu Feb 02, 2006 1:41 pm
- Location: San Antonio, Texas
- Contact:
OK
I think I see your point on dictionaries. So I will give you that one. I'll leave that for someone greater than I to tackle. To be totally honest here I have never scripted a dictionary usage script so I am unfamiliar with them enough to comment.
However, let's take the 200 integer example. Would not the file access to a text file slow down the server as well if we were to delete say the middle 7 integers? I mean we would have to take them out and move all entries down by 7 and rewrite the file out to the hard drive. In fact we'd be reading it in and then rewriting it so it would take doubly long since text files are not cached as are cfg files. Wouldn't all that file acces take just as long or longer as if we did that to a cfg file? If so why would the DeleteEntry be any better if it is reserved for text files only?
BTW I do understand the caching of cfg files in memory for faster access etc. And I can see how certain cfg files might be best left inaccessible if this function were implemented. Like I said earlier obviously messing with item or NPC cfg files would be a nasty bit of business.
Anyway, I may end up moving the golocs info to a text file so as to be able to implement deletion from within the .go command gump. Same for the sets info.
I think I see your point on dictionaries. So I will give you that one. I'll leave that for someone greater than I to tackle. To be totally honest here I have never scripted a dictionary usage script so I am unfamiliar with them enough to comment.
However, let's take the 200 integer example. Would not the file access to a text file slow down the server as well if we were to delete say the middle 7 integers? I mean we would have to take them out and move all entries down by 7 and rewrite the file out to the hard drive. In fact we'd be reading it in and then rewriting it so it would take doubly long since text files are not cached as are cfg files. Wouldn't all that file acces take just as long or longer as if we did that to a cfg file? If so why would the DeleteEntry be any better if it is reserved for text files only?
BTW I do understand the caching of cfg files in memory for faster access etc. And I can see how certain cfg files might be best left inaccessible if this function were implemented. Like I said earlier obviously messing with item or NPC cfg files would be a nasty bit of business.
Anyway, I may end up moving the golocs info to a text file so as to be able to implement deletion from within the .go command gump. Same for the sets info.
I'm not crazy about that idea. It works in theory, but reality isMarilla wrote:I'd actually like to see a full 'shell' ability, myself, without any checks done by the core for permissions at all. (since, IMO, permissions should be handled by the OS, not by POL;
something different. Opens up a can of worms that should better be
left closed in my opinion.
Xandros
By 'text files', I assume you mean 'DataFiles'. And yes, you are exactly correct; DataFiles take longer to load and use, and are not appropriate to use in a situation where you need 'instant' access to the information in them. This is precisely why the system is as it is now: One system for information that needs to be fully dynamic, and one for information that needs to load 'instantly'.Yukiko wrote:However, let's take the 200 integer example. Would not the file access to a text file slow down the server as well if we were to delete say the middle 7 integers? I mean we would have to take them out and move all entries down by 7 and rewrite the file out to the hard drive. In fact we'd be reading it in and then rewriting it so it would take doubly long since text files are not cached as are cfg files. Wouldn't all that file acces take just as long or longer as if we did that to a cfg file? If so why would the DeleteEntry be any better if it is reserved for text files only?
That's a good idea And thanks for being patient and understanding with my particular 'method' of explanation.Yukiko wrote:Anyway, I may end up moving the golocs info to a text file so as to be able to implement deletion from within the .go command gump. Same for the sets info.
I guess it just depends on what sort of access and abilities you have available concerning administration of the server, but systems much more complex than POL have had file-system permissions used to secure them for a long while. Remote UNIX Shell accounts would be basically impossible if this weren't something that any experienced administrator couldn't work on; It's probably not as easy as I might have seemed to make it sound, but it's certainly possible to 'lock down' a shell ability in POL (or any program) to have access only to known and desired processes.Xandros wrote:I'm not crazy about that idea. It works in theory, but reality is something different. Opens up a can of worms that should better be
left closed in my opinion.
And if you think about it, people really should be doing this even without a Shell ability. That is, if the 'can of worms' exists with a Shell ability, that can might already be opened... What if there is a buffer overflow vulnerability in POL that could be exploited by sending a particularly malformed game packet to the server? If you are running POL under the system/root account, it's game over (literally, perhaps).
Not saying that POL has any such vulnerabilities, but it's the job of a halfway decent sysadmin to protect against them; 'Layered' security, and all.
It's a fairly basic matter to set up an account specifically for POL, and then be sure POL only runs within the context of that user. Just to be 100% safe, on Windows 'system', or administrative users can actually have permissions denied, to make sure that even 'forgetfulness' doesn't cause POL to run with full privs.
Then you simply have to make sure that by default, the POL user has access to nothing at all on the system, and work up from there; Give it only the exact permissions it needs, and none it does not. For instance, the POL user doesn't need access to modify the POL binary itself.. only read and execute it. The need for writing to/adding config files can make it a little complex, but for most purposes, giving POL access to read, write, delete and add new files is fine, within it's own directory tree. Just be sure it isn't permitted to EXECUTE anything other than the POL binary itself. With a Shell ability, you would, of course, need to add more things to allow it to execute.
If you felt unsafe in allowing Shell commands in general, you could bypass that entirely, and simply write specific programs to do what you want, and only allow permissions to those programs, and any files/directories that program would need to alter.
As a simple example that most should be able to get, let's use the Windows/DOS 'del' command. This is actually a built-in command of the shell - it's not a separate 'program' that you could limit the POL user from accessing; If POL has the ability to open a Shell, it has the ability to run 'del'. So the trick then is to be sure that any FILES that 'del' could be used on are protected from the POL user. By denying everything by default, it won't matter that the POL user could call 'cmd /c del /q /s c:\winnt\*.*', because the POL user won't have any permissions (except read, where needed) to any of those files. But, the POL user could still shell "cmd /c del c:\pol\logs\oldlogfile.txt" without trouble, as it would have been given permissions to alter the c:\pol\logs\ directory, we presume.
However, all of that said, I do have to agree that there is definitely a big can of worms here; The fact is, most people (especially those on Windows) will simply run POL under the 'System', or an administrative account, so by default, POL would be able to modify, delete, execute anything, anywhere. Having a Shell option disabled by default, and also perhaps restricted to the POL directory tree by default, should handle most situations. But it is my personal belief that it's always best to give us the rope we need to do the things we would like to do; Let us be responsible for whether we use that rope to hang ourselves, or not.