[comp.sys.hp] ps lists command parameters

burzio@mmlai.UUCP (Tony Burzio) (03/04/90)

Does anyone know how to stop ps from listing the parameters
of a process owned by another user?  Some commands will
be put in square brackets, which means ps couldn't get the
parameters.  Is there a way to force this?  Thanks for any help!

uname: HP-UX mmlmfg 6.5 B 9000/370 mmlmfg

*********************************************************************
Tony Burzio               * Jus' waitin' for V7!
Martin Marietta Labs      *
mmlai!burzio@uunet.uu.net * Wow!  I could have a V8!
*********************************************************************

paul@hpldola.HP.COM (Paul Bame) (03/06/90)

'ps' gets program arguments by peeking into your program space.  When
you are swapped out it has to read the swap disc and may not bother so
instead you get square brackets - I think...

If you're just trying to obliterate your command-line arguments so
others can't see them, I've used the following:

	main(argc, argv)
	int argc;
	char *argv[];
	{
		char *saveit;

		if (argc >= 2)
		{
			saveit = argv[1];
			argv[1] = "obliterated";
		}
	}

In fact, once I replaced argv[0] (normally the program name) with a
string which reflected how many blocks it had processed so I could run
it forever in background and conveniently check (with ps) how far
it was in its task.  It's kinda cheezy but was more convenient than
writing a number in a file or to stdout or something.

	main(argc, argv)
	int argc;
	char *argv[];
	{
		char buffer[100] = "Hi!";
		int nblocks;
		...

		argv[0] = buffer;

		for(...)
		{
			...
			sprintf(buffer, "XX %d", nblocks);
			...
		}
	}

I've not done this with HP-UX for a while - and then it was on a 300 only
so there's no guarantee - but it's easy enough to try.

	-Paul

#include <disclaimer.h>

davidb@Pacer.UUCP (David Barts) (03/07/90)

In article <686@mmlai.UUCP>, burzio@mmlai.UUCP (Tony Burzio) writes:
> 
> Does anyone know how to stop ps from listing the parameters
> of a process owned by another user?  Some commands will
> be put in square brackets, which means ps couldn't get the
> parameters.  Is there a way to force this?  Thanks for any help!

Sure, do something like:

	/* set clobber[] to 50 blanks */
	char clobber[] = "                                                  ";

	main(argc, argv)
	int argc;
	char *argv[];
	{
		while(argc--){
			strncpy(*argv, clobber, strlen(*argv));
			++argv;
		}
		sleep(1000);
	}

This seems to work on HP-UX 6.2, and there's no reason why it shouldn't
work on 6.5.  No what's weird is that the following code *doesn't* work:

	main(argc, argv)
	int argc;
	char *argv[];
	{
		while(argc--){
			**argv++ = 0;
		}
		sleep(1000);
	}

Suppose this program is called `argtest'.  I type to the shell:

	$ argtest this is a test &
	4477
	$ argtest this is test one &
	4480

...and a ps -f will show 4477's argument list to be `est' and 4480's
to be ` rgtest his s est ne'!  Seems like ps is getting string sizes
somewhere and using memcpy() instead of strcpy().  But then it should
have gotten more args. for process 4477 than just `est'.  Strange...

However, back to the original question.  Overwriting the arguments
with blanks seems to work.  The first example will force ps -f to
place the name of the program in square brackets.  Nulls probably
would also work, but I didn't try them.
-- 
David Barts			Pacer Corporation
davidb@pacer.uucp		...!uunet!pilchuck!pacer!davidb

rer@hpfcdc.HP.COM (Rob Robason) (03/09/90)

> Does anyone know how to stop ps from listing the parameters
> of a process owned by another user?  Some commands will
> be put in square brackets, which means ps couldn't get the
> parameters.  Is there a way to force this?  Thanks for any help!

A word of caution about use of the techniques described in previous
responses to obliterate the contents of argv[]:  In the 7.0 release, due
to some changes in the way ps gets its data, the information printed by
default is NOT what is CURRENTLY in argv, but what was there at exec()
time.  To get ps to print the current values, you have to use the -m
option.  This makes the technique less useful.

You might note that only the -f option causes the argv[] stuff to be
printed, everything else, including the very similar -l option, prints
only the command name.  -l might be the right solution for this case.

Rob