how to set argv command line args for ps
g...@ll.mit.edu
I would like to write a C program (actually a library module for
python, but that's not important here) which changes it's argv, i.e.
which changes the
way it's arguments are shown by the "ps" command. When my application
loads
a new top-level data object, I want the data's name to show in the "ps"
listing.
This works easily under linux:
#include <unistd.h>
#include <string.h>
main(int argc, char **argv) {
strcpy(argv[1], "XXX");
sleep(120); /* go and look at "ps" output */
}
gcc -o mytest mytest.c
./mytest aaaa bb &
ps -o args 4391
COMMAND
./mytest XXX bb
How can I do this under solaris?
--- George
Casper H.S. Dik
>How can I do this under solaris?
You can't, except when you use /usr//ucb/ps to look at the argument vector.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Richard L. Hamilton
Casper H.S. Dik <Caspe...@Sun.COM> writes:
> g...@ll.mit.edu writes:
>
>>How can I do this under solaris?
>
> You can't, except when you use /usr//ucb/ps to look at the argument vector.
>
> Casper
Since sendmail is a program that modifies its args so you can tell what
each instance is doing, it makes a good example of this:
$ /usr/bin/ps -ef|grep sendmail|grep -v grep
smmsp 533 1 0 Oct 15 ? 0:01 /usr/lib/sendmail -Ac -q15m
root 1101 1 0 Oct 15 ? 0:15 /usr/lib/sendmail -bd -q15m
$
$ /usr/ucb/ps -auxww|grep sendmail|grep -v grep
smmsp 533 0.0 0.2 4456 1392 ? S Oct 15 0:01 sendmail: Queue runner@00:15:00 for /var/spool/clientmqueue
root 1101 0.0 0.3 4672 2408 ? S Oct 15 0:14 sendmail: accepting connections
$
This difference was quite intentional, 'way back (SVR2 at least, I think).
What /usr/bin/ps shows is (nowadays) pr_psargs from the psinfo struct
(used to be a field of struct user back in ancient history days, on some
flavors of Unix); that's effectively a snapshot of the 1st 80 characters
of the args at exec time, concatenated and separated by spaces. There are
two advantages to that:
* it's much easier and faster to retrieve than digging out the individual
args, which involves looking in the process's address space; with
structured /proc, it also requires no special privileges, while digging
the possibly modified args requires euid same as the target process, or
root. (it used to be even more complicated back before /proc - one
might have to dig into either memory or swap to find them)
* it prevents a process from concealing itself by changing that aspect of
its appearance. Of course, there are still other ways to hide...
and of course one disadvantage:
* the effort that some programs (like sendmail) make to use their args as
a way of showing their status is wasted
But on current Solaris, as Casper said (and the above example shows),
you have a choice, depending on which version of ps you use. Note: IIRC,
some very old versions of Solaris (somewhere <= 2.4, I think) might not
have had /usr/ucb/ps able to dig out modified args or environment
variables.
--
mailto:rlh...@smart.net http://www.smart.net/~rlhamil
Lasik/PRK theme music:
"In the Hall of the Mountain King", from "Peer Gynt"
Casper H.S. Dik
>* it's much easier and faster to retrieve than digging out the individual
> args, which involves looking in the process's address space; with
> structured /proc, it also requires no special privileges, while digging
> the possibly modified args requires euid same as the target process, or
> root. (it used to be even more complicated back before /proc - one
> might have to dig into either memory or swap to find them)
>* it prevents a process from concealing itself by changing that aspect of
> its appearance. Of course, there are still other ways to hide...
And:
* it's not possible when a process unintentionally modifies its enviroment
or argument vector to reveal private data.
>and of course one disadvantage:
>* the effort that some programs (like sendmail) make to use their args as
> a way of showing their status is wasted
>But on current Solaris, as Casper said (and the above example shows),
>you have a choice, depending on which version of ps you use. Note: IIRC,
>some very old versions of Solaris (somewhere <= 2.4, I think) might not
>have had /usr/ucb/ps able to dig out modified args or environment
>variables.
In S10, you'll only be able to do that on processes you can control.
Richard L. Hamilton
Casper H.S. Dik <Caspe...@Sun.COM> writes:
>
>>* it's much easier and faster to retrieve than digging out the individual
>> args, which involves looking in the process's address space; with
>> structured /proc, it also requires no special privileges, while digging
>> the possibly modified args requires euid same as the target process, or
>> root. (it used to be even more complicated back before /proc - one
>> might have to dig into either memory or swap to find them)
>
>>* it prevents a process from concealing itself by changing that aspect of
>> its appearance. Of course, there are still other ways to hide...
>
> And:
>
> * it's not possible when a process unintentionally modifies its enviroment
> or argument vector to reveal private data.
>
>>and of course one disadvantage:
>
>>* the effort that some programs (like sendmail) make to use their args as
>> a way of showing their status is wasted
>
>>But on current Solaris, as Casper said (and the above example shows),
>>you have a choice, depending on which version of ps you use. Note: IIRC,
>>some very old versions of Solaris (somewhere <= 2.4, I think) might not
>>have had /usr/ucb/ps able to dig out modified args or environment
>>variables.
>
> In S10, you'll only be able to do that on processes you can control.
>
> Casper
Which nicely addresses the point you raised.
Still, command line args (either way), as well as a number of other things
(file names, contents) _could_ be used to do evil things to root (or a
user eligible to see the data), if it was using a terminal on which escape
sequences could set and then report back strings. Of course that's
nothing peculiar to ps.
Casper H.S. Dik
>Still, command line args (either way), as well as a number of other things
>(file names, contents) _could_ be used to do evil things to root (or a
>user eligible to see the data), if it was using a terminal on which escape
>sequences could set and then report back strings. Of course that's
>nothing peculiar to ps.
Quite; that's why you shouldn't be using terminals with programmable
answerback sequences.
And the people who fixed "xterm should be able to report windowtitle"
in some versions of xterm have introduced a security probolem because of it.
Thomas Dickey
> And the people who fixed "xterm should be able to report windowtitle"
> in some versions of xterm have introduced a security probolem because of it.
more to the point: people who live in glass houses shouldn't throw bricks.
hmm - you've done nothing about dtterm, right?
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Richard L. Hamilton
Thomas Dickey <dic...@saltmine.radix.net> writes:
> Casper H.S. Dik <Caspe...@sun.com> wrote:
>> And the people who fixed "xterm should be able to report windowtitle"
>> in some versions of xterm have introduced a security probolem because of it.
>
> more to the point: people who live in glass houses shouldn't throw bricks.
>
> hmm - you've done nothing about dtterm, right?
>
For a 'bot that jumps on every mention of xterm (or is it just in c.u.s?),
he's got a point. From dtterm(5):
Esc [ p1 ; p2 ; p3 t
Window manipulation. Valid values for p1 (and
any additional parameters) are:
[...]
20 Report the dtterm(1) window's icon
label. The terminal emulator returns
``Esc ] L label Esc Backslash''.
21 Report the dtterm(1) window's title.
The terminal emulator returns ``Esc ] l
title Esc Backslash''.
Thomas Dickey
> For a 'bot that jumps on every mention of xterm (or is it just in c.u.s?),
> he's got a point. From dtterm(5):
well, as noted, Casper has two sets of standards - one for Sun and another
for others. We've been here before. See
(looking forward to Casper's announcement of an updated dtterm ;-)
John D Groenveld
Thomas Dickey <dic...@saltmine.radix.net> wrote:
>http://groups.google.com/group/comp.unix.misc/browse_frm/thread/160f49088ea66fb4/cf4b8f3ea569edfe?lnk=st&q=dickey+dik+dtterm&rnum=4&hl=en#cf4b8f3ea569edfe
>
>(looking forward to Casper's announcement of an updated dtterm ;-)
Is there an RFE for making answerback an option feature?
<URL:http://groups.google.com/groups?selm=casper.914508294%40nl-usenet.sun.com>
John
groe...@acm.org
Alan Coopersmith
|In article <11lqjl5...@corp.supernews.com>,
|Thomas Dickey <dic...@saltmine.radix.net> wrote:
|>http://groups.google.com/group/comp.unix.misc/browse_frm/thread/160f49088ea66fb4/cf4b8f3ea569edfe?lnk=st&q=dickey+dik+dtterm&rnum=4&hl=en#cf4b8f3ea569edfe
|>
|>(looking forward to Casper's announcement of an updated dtterm ;-)
|
|Is there an RFE for making answerback an option feature?
RFE's against dtterm are unlikely to go anywhere. CDE is pretty much
in sustaining mode, with minimal enhancements being made, and dtterm is
no exception. (dtlogin is the biggest exception, since it's still the
default login system for both CDE & GNOME.)
--
________________________________________________________________________
Alan Coopersmith * al...@alum.calberkeley.org * Alan.Coo...@Sun.COM
http://www.csua.berkeley.edu/~alanc/ * http://blogs.sun.com/alanc/
Working for, but definitely not speaking for, Sun Microsystems, Inc.
Colin B.
>
> well, as noted, Blah blah blah blah blah.
Oh yeah. I KNEW there was a reason you were killfiled.
John D Groenveld
Alan Coopersmith <al...@alum.calberkeley.org> wrote:
>RFE's against dtterm are unlikely to go anywhere. CDE is pretty much
>in sustaining mode, with minimal enhancements being made, and dtterm is
>no exception. (dtlogin is the biggest exception, since it's still the
Understood. An RFE, for the record, might be useful to those customers
who can't or won't follow Sun down the rabbit hole on Sun's timetable.
Please let us know if you spot CDE EOL notice in docs.sun.com release
notes or where ever the new policy states such customer notifications
of lifecycle changes should go.
John
groe...@acm.org
John D Groenveld
Michael Vilain <vil...@spamcop.net> wrote:
>Don't let the door bang you in the ass on your way out (unless you like
>that sort of thing)...
The risk for those of us who have entries like /Caspe...@Sun.COM/f:T+
or /sun.com/f:T+ in our killfiles is that out of deference, we'll allow
those we respect to slip down the slippery slope of double standards
and the cesspool of bullshit.
Bad idea. [tm]
John
groe...@acm.org
Alan Coopersmith
|notes or where ever the new policy states such customer notifications
|of lifecycle changes should go.
That's still the release notes. I wouldn't be at all surprised to
see one there in the release notes for the release currently code-named
"Nevada."
Thomas Dickey
> RFE's against dtterm are unlikely to go anywhere. CDE is pretty much
> in sustaining mode, with minimal enhancements being made, and dtterm is
> no exception. (dtlogin is the biggest exception, since it's still the
> default login system for both CDE & GNOME.)
It wasn't in sustaining mode when Casper started attacking xterm (and
ncurses) several years ago.
Thomas Dickey
> groe...@cse.psu.edu (John D Groenveld) writes in comp.unix.solaris:
> |Please let us know if you spot CDE EOL notice in docs.sun.com release
> |notes or where ever the new policy states such customer notifications
> |of lifecycle changes should go.
> That's still the release notes. I wouldn't be at all surprised to
> see one there in the release notes for the release currently code-named
> "Nevada."
That sounds like it'll just leave gnome-terminal and some flavors of xterm
(including Sun's color xterm ;-). And of course the non-X Sun console that's
more than once been the subject of some confusion this year.
It would be nice if Casper were able to direct his remarks about the topic
to _constructive_ comment telling how Sun has patched gnome-terminal to avoid
the problem that he's concerned about. google doesn't show me any instance
where Sun is reported to have patched gnome-terminal ...
Rich Teer
> groe...@cse.psu.edu (John D Groenveld) writes in comp.unix.solaris:
> |Please let us know if you spot CDE EOL notice in docs.sun.com release
> |notes or where ever the new policy states such customer notifications
> |of lifecycle changes should go.
>
> That's still the release notes. I wouldn't be at all surprised to
> see one there in the release notes for the release currently code-named
> "Nevada."
Change and progress is inevitable, I guess, but dropping CDE before
JDS/GNOME's issues are sorted out (wrt meeting the needs of CDE users)
would be a mistake IMHO.
--
Rich Teer, SCNA, SCSA, OpenSolaris CAB member
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich
Alan Coopersmith
|On Tue, 25 Oct 2005, Alan Coopersmith wrote:
|
|> groe...@cse.psu.edu (John D Groenveld) writes in comp.unix.solaris:
|> |Please let us know if you spot CDE EOL notice in docs.sun.com release
|> |notes or where ever the new policy states such customer notifications
|> |of lifecycle changes should go.
|>
|> That's still the release notes. I wouldn't be at all surprised to
|> see one there in the release notes for the release currently code-named
|> "Nevada."
|
|Change and progress is inevitable, I guess, but dropping CDE before
|JDS/GNOME's issues are sorted out (wrt meeting the needs of CDE users)
|would be a mistake IMHO.
Given the current 2-3 year release cycle for full Solaris releases, if
it appeared in the Nevada release notes, that would give about 5 years
from now to work out JDS/GNOME's issues before a Solaris release without
CDE. If there are issues you think need to be worked out in that time
for you to be willing to switch, I'm sure the OpenSolaris Desktop
community discussion groups would be happy to hear them (and that
applies to everyone, not just OpenSolaris CAB members 8-) ).
Some may even be worked out in the GNOME 2.12 update they're working to
release via opensolaris.org RSN.
Of course, any EOF date for CDE is all speculation and predictions at
this point. (Though somewhat informed speculation on my part - not a
completely wild-assed guess, but not something I can say is definite one
way or the other yet.) I'm sure you'll hear much more as we get closer
to it actually being set. Maybe we'll even get the EOF discussions held
in the OpenSolaris Desktop community lists when it's time for those,
much like the recently posted (and much less interesting) EOF proposals
in other OpenSolaris forums.
(Which reminds me, I should probably forward on the EOF proposal I
recently sponsored for the closed source Xsun drivers for x86, now
that both the open source XF86-* modules for Xsun and Xorg itself are
available as replacements. Again, much less interesting and
controversial than CDE.)
Rich Teer
> CDE. If there are issues you think need to be worked out in that time
> for you to be willing to switch, I'm sure the OpenSolaris Desktop
> community discussion groups would be happy to hear them (and that
> applies to everyone, not just OpenSolaris CAB members 8-) ).
:-)
I'll draw up a list of my GNOME issues and see what happens.
> Some may even be worked out in the GNOME 2.12 update they're working to
> release via opensolaris.org RSN.
Indeed.
> Of course, any EOF date for CDE is all speculation and predictions at
> this point. (Though somewhat informed speculation on my part - not a
> completely wild-assed guess, but not something I can say is definite one
One question comes to mind WRT EOLing CDE: isn't it required for UNIX 98
(and presumably later) certification? Or is that the "Desktop" variant
only?
Alan Coopersmith
|(and presumably later) certification? Or is that the "Desktop" variant
|only?
CDE is required for Unix 98 Workstation branding. Last I checked there
was no Workstation/Desktop variant of Unix 2003. Whether or not anyone
still asks for Unix 98 Workstation certification in their RFP's is a
question for Sales/Marketing, not something I can answer.