On Aug 22, 2009, at 6:57 AM, casper....@sun.com wrote:
So a situation at $WORK today has me wondering something - why is it
that the pr_psargs member of psinfo is limited to 80 bytes
(therefore,
characters) ? Is this mainly due to historic reasons?
Well, /proc uses public structures; once they're defined, you cannot
change them.
But there are two parts of this: psargs is copied when exec is
performed;
if you want to get more, you will need to copy more.
I realize that expanding the size of that member will certainly break
binary compatibility, but I can't think of any security implications
for properly storing and revealing more of a process's arguments,
perhaps in a new structure or other appropriate facility where it can
be programatically retrieved with out requiring elevated privs and
the
shenanigans that pargs(1) goes through to get the full arg list of a
pid.
We can probably change ps to report more of pargs and environments but
only if you have permission to open the specific process, like
pargs(1).
If you want to report *everything* you MUST copy the complete argv[]
vector at exec time (max 2MB). You can't use the mechanism pargs uses
because applications can and will modify argv[][] and pargs can report
private memory which isn't part of the original argv[] and that's
where
the security issue is.
So the options are:
- copy more when the program is execed (80 is apparently not
enough, but what is, do we really need to copy everything?)
I gather the historical reason for the 80 byte limit is that it was
decided at a time when memory was more scarce and filling it with the
complete argv[] of every process was perhaps excessive and wasteful.
Maybe 80 was decided because that matches the standard terminal width,
as well. Who knows.
This issue pops up once in a blue moon for me, and judging from some
googling, others as well throughout history. A lot of "Linux shows
everything, why doesn't Solaris..." etc etc.
I would say that copying up to 2MB might be excessive, but I'm sure we
can certainly accommodate more than the 80 bytes we get now. The issue
that brought this up at work for me recently has to do with some
process monitoring involving JVMs with some quite long argument
strings. The monitoring system was determining the job of each JVM by
keying in on a particular argument which didn't make the cut off in
pr_psargs. The work around of course would be to position that
argument earlier (first) in the list when exec'ing the JVMs, but it's
still pretty annoying none the less on top of having to explain the
differences between Solaris and Linux to non-OS-savvy folk.
- report more of argv but only for "your" processes.
Less consistent, less optimal of a solution.
/dale
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
