Open Source TN5250 Emulator

James Rich | 21 Nov 2007 01:28

Re: Remembering page state between print jobs

On Tue, 20 Nov 2007, Scott Klement wrote:

> IMHO, the stuff related to parsing SCS should remain in the SCS
> programs.  Remember: SCS is not the only printer language that the
> system supports.  We'll want to support AFP, IPDS, USER-ASCII, etc in
> the long run.
>
> Plus, I think it's really handy for debugging and development to be able
> to dump the SCS data to a file and be able to analyze that file, and run
> it through other tools like scs2ascii or scs2pdf later on.

I agree on both points.

> Can scs2pdf simply save the settings it needs into a file on disk?

I thought about this.  I just don't think it is a very elegant solution. 
The problems I see with this are:

1. What happens if the file is deleted between print jobs?
2. What security implications are there? Specifically, how do we avoid 
creating a file that someone has cleverly linked to an important system 
file, ownerships, etc.

This solution does provide for repeatability when piping raw SCS output to 
scs2pdf without using lp5250d during debugging sessions like you mention.

Personally, I would prefer that lp5250d remembered the settings.  Then is 
could invoke the scs2* programs with command line arguments such as 
--pagewidth=X etc.  This also provides for repeatability when debugging. 
But I can't come up with a nice way to do that.  So barring some brilliant

(Continue reading)

headers

Scott Klement | 21 Nov 2007 03:01

Re: Remembering page state between print jobs

James Rich wrote:
> The problems I see with this are:
> 
> 1. What happens if the file is deleted between print jobs?
> 2. What security implications are there? Specifically, how do we avoid 
> creating a file that someone has cleverly linked to an important system 
> file, ownerships, etc.

By that logic, nobody should ever use files for any reason.

What happens if someone deletes ANY file on your system?  Wouldn't that 
cause a problem?  Surely users know better than to delete random files. 
  Those that don't shouldn't be given access to important files -- 
including the stuff that lp5250d saves.

How do you prevent lp5250d from overwriting an important system file 
thanks to some clever link?  Well... uhh... you don't run lp5250d as 
root, do you?

I suppose if you're really worried about it, only have lp5250d open a 
file if it doesn't exist.  That way, you know it can't be pointing to a 
system file -- since system files already exist :)  Have it use the file 
to remember the settings while lp5250d is active, and when lp5250d ends, 
have it delete the file.  This will also serve to protect you from 
having multiple lp5250d jobs trying to use the same file (which probably 
wouldn't be good.)
--

-- 
This is the Linux 5250 Development Project (LINUX5250) mailing list
To post a message email: LINUX5250@...
To subscribe, unsubscribe, or change list options,

(Continue reading)