RE: [hpoj-devel] ptal-printd, and preparing for 0.7

[PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...>]

Hi, Joe.

Joe Piolunek wrote:
> This release looks like it will be a genuine improvement over 
> the last one. 
> Installation and use should be a lot easier. 
Thanks!  I'm glad you like it.  Normally I prefer to avoid major last-minute
changes like this, but under the circumstances I think it's justified.

> When using the recommended options, the security of the pipe 
> is a lot better. 
> Logged in as a user, I couldn't send it data directly, but 
> had to go through 
> lpr. 
Good.  There were two problems I was trying to prevent by tightening up the
permissions on the pipe: arbitrary users' connecting directly to the pipe
and dumping extra data to the pipe while somebody else is printing through
lpd (thereby mangling the job), and arbitrary users' reading from the pipe
and snooping on other users' print jobs.  (I'm not sure how Unix named pipes
handle the cases of multiple readers or multiple writers.)

> Is there any reason for ptal-printd to be started by an 
> ordinary user? If 
> not, you may want to install ptal-printd with its permissions 
> set at 744, the 
> same as lpd. After installation, I tightened up the 
> permissions and rebooted. 
> Everything still works.  
Is there any reason for ptal-printd not to be started by an ordinary user?
It probably won't be useful to most people, but I found it handy while I was
developing it.  In any case, the normal Unix protection mechanisms should
prevent a non-root user from doing anything dangerous with ptal-printd, and
the "-pipepath" option lets one specify a different directory from the
default of /dev/ptal-printd.  Similarly, lpd is prevented from binding to
port 515 or writing to /var/spool/lpd when not run by root.  I think the
only reason not to give world-execute permission would be to reduce
confusion for users who inadvertently start it.  Malicious users can always
build and run their own copy.  After all, people can still run
ieee12844_print or ptal-connect, which is essentially what ptal-printd does,
just in a more useful way.

> I got an unexpected result when trying to start ptal-printd 
> without options 
> from the command line (as a user).  When I used the command  
> 'ptal-printd &'  
> the options list was displayed, but the prompt didn't come 
> back until I typed 
> ^C.
I think this is a feature of bash, not a bug in ptal-printd.  When I do this
on my system, I get the line showing the job number and process ID followed
by a shell prompt, followed by the output from ptal-printd.  If you press
Enter again you should see a message indicating that the process exited
followed by another prompt, just as you saw when you pressed ^C.  When I do
this multiple times, sometimes the prompt is before the output and sometimes
it's afterwards, depending on whether the shell or ptal-printd gets more CPU
time.  On the other hand, tcsh does this as soon as a background process
exits without waiting for you to press Enter.

> You may want to add a warning somewhere to not run two 
> instances of xojpanel 
> or keep it running while starting a second print job. If I 
> forget to kill 
> xojpanel first, ptal-printd dies and won't run again until 
> xojpanel is also 
> killed from the command line. That's likely to be a common 
> annoyance for 
> users, unless they just decide not to use xojpanel.
OK, I'll try to make this clearer.  However, I would like to position the
"Bugs and TODO" web page to be the official source for this information,
since that's the most up-to-date resource, particularly for bugs found after
a release or bugs that have patches or workarounds.

> I noticed a couple of typos close together in the 
> PRINT-HOWTO, so I ran the 
> spellchecker on it. I found a total of only about 3 or 4  
> spell/typo errors, 
> (pretty good  for most people). To save you some time, I made 
> a patch that's 
> attached below.
Thanks!  I'm surprised there weren't more typos.  It was four in the morning
when I wrote that and I was half asleep.  :-)  I don't agree that
"inter-operable" has to be hyphenated, but I changed it anyway to keep
spell(1) happy.

> Those results are worse than mine.  The no-start problem 
> *itself* isn't a big 
> one, since it's easy to click again on the icon. Many users 
> may not even 
> notice it. In case it happens to affect something else 
> though, it's better to 
> find it (and fix if possible) IMHO. I hope it does get fixed 
> sometime before 
> 0.8.
I'll try to find time to look into it further in the next couple of days, or
in the near future at least, but I need to get 0.7 out before the upcoming
holidays get in the way.

David