The underlying limitations are this:
* since (I think) SVR2, the OS saves 80 characters of the strings pointed to by 
the argv[] array (with spaces between the strings), to make it easy for ps to 
obtain enough command line info for a traditional 80-character CRT (the 
modified version on the AT&T 7300 aka Unix PC saved less than 80 characters I 
think, to conserve memory), and to provide a copy of the command line that 
cannot be concealed by the process.  On the one hand, that means that 
"evil_proc" cannot pretend to be "good_proc", but on the other, it means you 
shouldn't pass anything sensitive on the command line...although it should be 
possible to lock down ps so that one can only see one's own processes (how 
might depend on the availability of e.g. fine-grained permissions, or else 
might require changing ps a little).

* Before SVR2 (and after I think, at least for a time, in *BSD), digging out 
the args actually passed to the command was done.  More recent than SVR2 was 
the addition of /proc, which makes digging out the real args a little easier, 
if still not quite as easy as retrieving the saved command line (the latter 
also being readable by anyone with basic privs, while the full data needs root 
or process owner to dig it out).  So /usr/ucb/ps auxww and such will only show 
full command lines for your own processes, or for everyone's if you're root (or 
if it's setuid, which I think it was on some older versions?).

Any process can alter its actual args, although not (as previously mentioned) 
the saved command line copy.  For example, sendmail does that on purpose, to 
show what each of potentially multiple sendmail processes is doing.  BSD style 
ps as root with the axww options will show that.

>From whatever Solaris version first introduced it, the "pargs" command can 
>also show full command lines, although with each arg as a separate line.
-- 
This message posted from opensolaris.org
_______________________________________________
opensolaris-help mailing list
opensolaris-help@opensolaris.org

Reply via email to