Full command line arguments/process status

[Lenny Tropiano]

In article <15656 at electron.mips.COM> wilkes at mips.COM (John Wilkes) writes:
|>In article <1818 at umbc3.UMBC.EDU> alex at otter.UMBC.EDU (alex) writes:
|>|In article <455 at polyof.UUCP>, john at polyof.UUCP ( John Buck ) writes:
|>|
|>|> Being that the response was so large, I have decided to post the
|>|> uuencoded/compressed(b12) program.
|>|
|>|	With all respect for John for posting his work, I can't help but be
|>| [...]
|>|disturbed and insulted by the binary-only distribution of this
|>|program. I for one would never consider using a binary without source,
|>
|>I really dislike seeing content-free postings that merely say, "Yeah, what
|>he said," but I am compelled to post just such a thing right now.
|>

Just like John Wilkes and Alex Crain, I feel *very* compelled to comment
on this issue.  It's funny, I probably was one of the key people who
started this whole thing.   About 1 year ago, a discussion started on the
net about getting ps(1) for the UNIX PC to display all the command arguments. 
It was noted back then, by myself and other people that only the first
14 characters of the command were saved in the user structure.  This is
unlike other UNIX machines that will display the entire list of command
line arguments when ps(1) is invoked with the "-f" command.  John Buck
replied in saying that the arguments are available if you can read them
off the user's stack space (since exec uses this area).  He mentioned that
he would post his program if he was able to get time port it to the UNIX PC.
About 2 weeks ago, I was going through some old mail, and I found his letter
to me.  I replied again to him, in hopes that he had finished he program, 
since I was about to undertake the project myself.   Obviously he finished
the extend-ps part of his "stat" program, hence his postings about it.

|>I, too, was distrurbed by seeing a binary-only posting to this group.
|>The description of the program is intriguing, and it sounds like a useful
|>tool.  However, I have no intention of running a setuid program without
|>first at least glancing at the source to see what it does.  In fact, I have
|>no intention of running *any* binary that comes off the net.  If I can't
|>have the source code, I'm not interested.  I wonder how many unix-pc owners
|>share this opinion?
|>
...
Binary postings to the net have really no place.  In this age of "virus" and
"worm" programs, I would be very leary in running *anyone's* binary posting,
if it wasn't accompanied with the source code.   Yes, I agree the program does
have good uses, but certainly doesn't outweigh the hazards of running any
binary posting.  Not to mention that you would have to run the program setuid
to read the files /dev/kmem, /dev/mem, and /dev/swap.   John Buck covers himself
in saying:

[...from the README file that came with the stat binary distribution...]

|*----------------------------------------------------------------*
|* Disclaimer: I am not responsible for any side-effects this     *
|*    program may have.  Carefully read the information below     *
|*    and make sure you understand it.  Stat will overwrite a     *
|*    file in /etc (/etc/stat_nl).  Be sure you do not have a     *
|*    file by this name.  Stat reads system memory (/dev/mem,     *
|*    /dev/kmem, /dev/swap).  It is possible for stat to get      *
|*    bad pointers internally and reference possibly illegal      *
|*    addresses.  This could, theoretically, cause system crashes *
|*    Bad pointers are possible due to the fleeting nature        *
|*    of some of the data in the OS.  You run this program at     *
|*    your own risk.                                              *
|*----------------------------------------------------------------*
...
|'stat' does NOT have to be made 'sbit'.  It does, however, require
|read permission on the following files:
|	/dev/swap
|	/dev/kmem
|	/dev/mem
|	/unix
|	/etc/mnttab
|
|It also requires both read/write access to (an empty file): /etc/stat_nl
|You can do:
|	chmod 666 /etc/stat_nl >/etc/stat_nl
...
|
|If you are paranoid, just make sure all the files above are accessible
|by stat.

Changing the permission on the /dev/*mem files would only compromise the
security of your UNIX pc even more than it already is.  Readable memory
just prompts someone to scan the /dev/*mem files with "strings" and find
things like the "root" password in it.  When you login as root, the password
is in the tty buffers unencrypted, right?  And the buffers are in memory 
right?  Believe me I saw my root password there!

Now someone is going to come back and say, "But the UNIX pc has many more
ways to become root, break-in, compromise security..."  My answer is *why*
make it any easier?  I'm sure we've all tried to tighten security in some
way or another (and probably fighting a loosing battle) ...

|>|	I also think that this sets a bad precident. One of the
|>|biggest advantages of the unix-pc is the volume of free software
|>
|>Indeed.
|>
|>|(emacs? gcc? shcc? sh-ld?  ptys? capcntrl?)
|>
|>mtools? pcomm? xmodem? kermit? patch? news? rn? less? sc? nbs_time? windy?
|>The list is infinite.
|>
|>Another advantage is the community of unix-pc owners.  I have received an
|>incredible amount of help and support from strangers, none of whom have
|>ever asked for compensation.  I've even offered meager assistance to others
|>when I've been able, and I've never sent a bill.
|>
...
We've all contributed in some way to the net, if it's not like myself who
has been an active participant with the unix-pc world with source postings,
discussions, helpful hints, etc..., it's been the learning experience with
great deals of information for a machine that is no longer supported with 
much vigor by it's vendor.   The wealth of information from the net has
been worth more than the information that we get from AT&T, I'm sure most of us,
yes, including myself, would feel it's been a learning experience for them.

|>|	I realize that this is a religious issue, but I am a religious 
|>|person, and something had to be said.
|>
|>Me, too.  I hope that John reconsiders his position and posts source for
|>his program.  I'm certain that I could learn something from it.
|>
...
I'm certain I could learn from it too.  I wouldn't have any bad feelings 
about running it on my machine if I could glance on how it worked.  
And if it crashed at least have the ability to see if I could fix it!   
Surely nothing is that difficult, and since we all know it can be done, 
why can't someone else write it now.  Even if it's unfinished, I would 
hope John Buck reconsiders ... We all aren't perfect, and I'm sure there
are potential problems with John Buck's "stat" program, so why not post
the source and have the net show you a thing or two...  In my opinion the
net is the world's largest source debugger :-)  Until then, if that ever
occurs, the best spot for his binary is saved to /dev/null.

-Lenny
-- 
Lenny Tropiano             ICUS Software Systems         [w] +1 (516) 582-5525
lenny at icus.islp.ny.us      Telex; 154232428 ICUS         [h] +1 (516) 968-8576
{talcott,decuac,boulder,hombre,pacbell,sbcs}!icus!lenny  attmail!icus!lenny
        ICUS Software Systems -- PO Box 1; Islip Terrace, NY  11752