ps permissions

[Tim Medford]

I would like to change the permissions on the ps command so that the "other" group cannot use it.

When we run database imports, the developers can use ps to see the userid/password on the imp command and I'm trying to prevent this.

Is there any risk in doing this?

Thanks,
Tim

[Stuart Abramson_2 · Accepted solution]

I don't mess with UNIX commands.

Here's a risk:

There could be 10,000 scripts running out there with "ps -ef | grep "STRING" " statements in them and they will all abort, and it will be your fault.

If Oracle doesn't know enough to hide their stupid ID/passwords, then it's not your responsibility to cover it up. We have the same problem with Oracle Applications, and it's just the way it is.

BTW, nobody ever figured out the Oracle Apps passwords.... Users just don't think of it.
(You can't take that to the bank, of course...)

[A. Clay Stephenson]

The problem is that other scripts may depend upon ps. You could create a wrapper ps and put it in something like "usr/local/bin/ps" and make the PATH use the wrapper before /usr/bin. The wrapper would then call the "real" ps.

The real problem is not ps but rather the practice of sending plaintext in the command line. I would put the username/password in the exp parameter file and make the permissions of the paramter file restrictive.

Plan B. Let the user be authenicsted by the OS just as you would for SQLPlus. I think external authenication works for export but I can't remember trying it.

[Chris Watkins_1]

No points, no hard feelings, if this isn't the answer you want:

Still, I have to voice the opinion:
This is the tail wagging the dog, if I ever saw it.

I'd say the import method needs changing... not the "ps" command.

There are a few ways around this, including the "hide"
command that you can get and compile... another is by
piping the password to the import command, instead of including it.

Shame on Oracle, for not making this an easier task.



If you still wanted to cripple users' ability to use "ps",
I suppose you could do that. I can't think of anything
right off that would break, unless they've got scripts
that require a functional "ps" command to work correctly.

I suppose you could also wrapper ps in such a way
that it checked uid, and ignored sql, import, and other
oracle commands for users not in a specific group, if you wanted.

[Gary L. Paveza, Jr.]

We force Oracle to use OS Authenticated user IDs. That way, all userID and passwords are handled by the OS itself. You don't need to worry about user names and passwords showing up in the process tree that way.