Disable shell escapes? about zork HOT 6 OPEN

Thank you. I should have updated my post. I *think* I found a way around the issue. I had to make a front end for zork that prevents the user from getting to a shell. I did it by having every user run his own game in his own directory with no shell ... Here is my script: #[Intro] read -p "Press a key to start." cd /usr/games/zork if [[ ! -e ./$USER ]] then mkdir $USER cp zork $USER cp dtextc.dat $USER cd $USER else cd $USER fi PATH=/usr/games/zork/$USER SHELL=/bin/false /usr/games/zork/$USER/zork . /home/gameplayer/.bashrc # return $USER to the gameplayer shell upon normal exit from the game Here is what happens when the user tries to access a shell: You are in an open field west of a big white house with a boarded front door. There is a small mailbox here.

sh: 1: cmd: not found

sh: 1: bash: not found

sh: 1: sh: not found

I don't understand that.

I don't understand that.

Nice weather we've been having lately. ## Is this built into the game?

Your score would be 0 [total of 585 points], in 4 moves. This gives you the rank of Beginner. Do you wish to leave the game? n

You are in a forest, with trees in all directions around you.

I don't understand that.

sh: 1: bash: not found

Connection to iwastrel.com closed. That seems to work. If you see any flaws, please tell me. Eric http://iWastrel.com

There are indeed flaws, such as echoing environmental variables:

/usr/games/zork/honeybunch

/bin/false

/home/gameplayer and

dsave.dat dsavec.dat dtextc.dat hello zork It looks like someone could execute a forkbomb though... Eric http://iWastrel.com

Welcome to Dungeon. This version created 11-MAR-91. You are in an open field west of a big white house with a boarded front door. There is a small mailbox here.

sh: 1: Syntax error: Bad function name

Nope. (Yes, I did try it.) "The issue of accessibility to your SSH is essentially equivalent to the issue of accessibibility to business systems on business time, so it should be treated in an analogous way." I have little understanding of what that means... but I plan to keep ssh access open 24/7/365 so I will do nothing about accessibility. Eric http://iWastrel.com

This is actually a point where the function protct() (or PROTCT() in the Fortran version) would be used. In the C version in the file np.c is: // NO SHELL ESCAPE /+TAA+/ if (buffer[0] == '!') {    system(buffer + 1);    goto L5; } so the appropriate adjustment would be if (buffer[0] == '!' && ... a check involving protct() ...) {    system(buffer + 1);    goto L5; } Inside the protct() function, itself, is where you'd want to insert the various conditions or checks you're trying to do on the outside with shell scripts. In the Fortran version (at least in my copy, now), the corresponding code in np.f (or np.for) is commented out and there are no shell escapes at all. In the original sources, a distinction was made between what type of input device (if any) the user had; in order to control how the output was "paged" or (more generally) broken up or parcelled out. It was disabled, but kept around as unused legacy code. That's actually the place where it would be most appropriate to put in networking-dependent or windowing-dependent code, as well, generalizing the concept of "terminal" to "network connection" or "window", and perhaps reusing some of those legacy routines to that end. Note, for instance, that "crows" and "coutput" are mostly unused. In a windowed input device, that might be used to track the location of the output on a window and the dimensions of the window. There is no harm in using the system copy of the *.dat files. They are read-only and both the C and Fortran programs are very stringent about buffering - the Fortran version more so. In my copy of the C version of Zork, you'll see that I retrofit part of the Fortran original back in, made the input routine buffered again, rather than character-based, and separated back out the "story" database from the "index" database - as they are in the Fortran version. The access to the story database are in the dsub.c and dsub.f files and is confined to the routine GetRec() in both the C and Fortran versions. The file is accessed as a stream (which you can do in Fortran now, but not in Fortran 77). Nonetheless, items are buffered. In the modified version of both the Fortran and C code and the original version of the Fortran code, the record-retrieval is inside a loop, because an output may span multiple records, so it could overshoot the message boundary, if the file is corrupted. But, there is an end-of- file check in the routines, both original and modified. In the 1991 translation of the C code, access was character-based as a stream, so the loop was a one-character-at-a-time read routine. But, it also had an end-of-file test. I set up a decompiler routine in the modified sources (readit.c and readit.f), so you can view the contents of the story and index files. I also wrote a re-compiler (writeit.c and writeit.f), but haven't yet added them to the source files. Version 4 of the Fortran source, by the way, has a story and index file compiler. It keeps the story and index database files separate, as does version 3, and uses fixed-length buffering, like version 3; not streaming, as I do now. When I get more time, I will add version 4 to my copy of the Zork source and try to finish linking up the github history-streams of all the versions I have. (My copy of "zork" is currently mirrored in the "C1991" directory of my copy of "zork- fortran", and is identical to the newer C translation in "C2021" under zork-fortran, but they haven't yet been merged.)

Dear Lydia, Thank you for your continued interest. I don't have the code to modify, I have no need for the code, and changing it may be beyond my ability, anyway. My rather clumsy solution works. It's not possible for a user to escape to a shell or execute anything that requires a shell. I think the thread should be closed. Nobody uses my ssh connection anyway. Nobody wants to play text games. And I have moved on to other things. Eric http://iWastrel.com

This is actually a point where the function protct() (or PROTCT() in the Fortran version) would be used. In the C version in the file np.c is: // NO SHELL ESCAPE /+TAA+/ if (buffer[0] == '!') { system(buffer + 1); goto L5; } so the appropriate adjustment would be if (buffer[0] == '!' && ... a check involving protct() ...) { system(buffer + 1); goto L5; } Inside the protct() function, itself, is where you'd want to insert the various conditions or checks you're trying to do on the outside with shell scripts. In the Fortran version (at least in my copy, now), the corresponding code in np.f (or np.for) is commented out and there are no shell escapes at all. In the original sources, a distinction was made between what type of input device (if any) the user had; in order to control how the output was "paged" or (more generally) broken up or parcelled out. It was disabled, but kept around as unused legacy code. That's actually the place where it would be most appropriate to put in networking-dependent or windowing-dependent code, as well, generalizing the concept of "terminal" to "network connection" or "window", and perhaps reusing some of those legacy routines to that end. Note, for instance, that "crows" and "coutput" are mostly unused. In a windowed input device, that might be used to track the location of the output on a window and the dimensions of the window. There is no harm in using the system copy of the *.dat files. They are read-only and both the C and Fortran programs are very stringent about buffering - the Fortran version more so. In my copy of the C version of Zork, you'll see that I retrofit part of the Fortran original back in, made the input routine buffered again, rather than character-based, and separated back out the "story" database from the "index" database - as they are in the Fortran version. The access to the story database are in the dsub.c and dsub.f files and is confined to the routine GetRec() in both the C and Fortran versions. The file is accessed as a stream (which you can do in Fortran now, but not in Fortran 77). Nonetheless, items are buffered. In the modified version of both the Fortran and C code and the original version of the Fortran code, the record-retrieval is inside a loop, because an output may span multiple records, so it could overshoot the message boundary, if the file is corrupted. But, there is an end-of- file check in the routines, both original and modified. In the 1991 translation of the C code, access was character-based as a stream, so the loop was a one-character-at-a-time read routine. But, it also had an end-of-file test. I set up a decompiler routine in the modified sources (readit.c and readit.f), so you can view the contents of the story and index files. I also wrote a re-compiler (writeit.c and writeit.f), but haven't yet added them to the source files. Version 4 of the Fortran source, by the way, has a story and index file compiler. It keeps the story and index database files separate, as does version 3, and uses fixed-length buffering, like version 3; not streaming, as I do now. When I get more time, I will add version 4 to my copy of the Zork source and try to finish linking up the github history-streams of all the versions I have. (My copy of "zork" is currently mirrored in the "C1991" directory of my copy of "zork- fortran", and is identical to the newer C translation in "C2021" under zork-fortran, but they haven't yet been merged.) — Reply to this email directly, view it on GitHub<#13 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAUIWIUAOFPVDH7R7CVTWXTUSPG6XANCNFSM4PR6BJ3A>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>