Sys Admin Best Practices - Justification for /usr/ucb/ps truncating at 80 characters after 10221
I am advised that a recent patch was added prevent one user seeing the environment variables in force in processes running as other users.
As an unfortunate side effect, users can now only see the first 80 characters of command line for processes owned by other users.
Naturally root still sees all (but I'd rather not resort to running things as root, just to query system status).
I understand that in most (but not) cases the user wanting to "ps | grep" will be the user that started the process, or indeed root. But I beleive that there are cases where this is not true or desirable.
For example, many Java processes have ridiculously long command lines, and as as a regular user, without root or an application runtime account, or other monitoring tools, I may wish to easily and quickly determine that WebSphere, WebLogic, whatever, ... is running with the correct arguments.
I can no longer do this.
It also seems that the limit of 80 is somewhat arbitrary.
Passwords on the command line shouldn't appear at all, and we can't claim they'd always be in characters 81 onwards.
So, is there a hard justification for why this has to be like this?
Or could this be improved so that the full command line is available evn though the environment is not?
I'd also argue the regular ps should display the full command line also, like certain other UNIXes.
Do other customers feel as I do...?
{{{ Andy
[1482 byte] By [
andykeya] at [2007-11-26 23:08:20]
# 1
I am advised that a recent patch was added prevent
one user seeing the environment variables in force in
processes running as other users.
As an unfortunate side effect, users can now only see
the first 80 characters of command line for processes
owned by other users.
Naturally root still sees all (but I'd rather not
resort to running things as root, just to query
system status).
I understand that in most (but not) cases the user
wanting to "ps | grep" will be the user that started
the process, or indeed root. But I beleive that there
are cases where this is not true or desirable.
For example, many Java processes have ridiculously
long command lines, and as as a regular user, without
root or an application runtime account, or other
monitoring tools, I may wish to easily and quickly
determine that WebSphere, WebLogic, whatever, ... is
running with the correct arguments.
I can no longer do this.
It also seems that the limit of 80 is somewhat
arbitrary.
Passwords on the command line shouldn't appear at
all, and we can't claim they'd always be in
characters 81 onwards.
It's different data.
The execution string shown by '/usr/bin/ps' (and by /usr/ucb/ps when privileges do not exist for the process) is stored in the kernel. To cap the potential memory hit, this string is limited to 80 characters. It is arbitrary, but hardcoded.
This string is owned by the kernel, so showing it to non-privileged users is straightforward.
The full execution string (and environment) is owned by the process. Allowing non-privileged users access to that data, but not access to other data in the process is tricky. So it is currently limited. When access is available, either 'pargs -a <PID>' or '/usr/ucb/ps ww <PID>' can display the contents. Of course the process can modify that information (for good or evil purposes).
You could make /usr/ucb/ps setuid if you wanted to allow non-privileged users access to that data.
So, is there a hard justification for why this has to
be like this?
Or could this be improved so that the full command
line is available evn though the environment is not?
I'm sure there's no hard justification for 80 vs 81. But argument strings can be quite large and you can have a very large number of processes. So a limit was picked that would generally give good visibility to the process launch while still limiting impact.
I'd also argue the regular ps should display the full
command line also, like certain other UNIXes.
Unfortunately, the information in the kernel string and the information in the process environment can be very different. There is a long history of '/usr/bin/ps' returning the safe (but short) value stored in the kernel. Changing that shouldn't be done lightly.
However, you could file a bug or RFE on bugs.opensolaris.com and discuss it with others.
Given that 'pargs' exists, I don't think a lot of folks are going to want to change the current behavior.
Also, you still have to work out how to avoid the security issues with viewing that string when you don't have privileges.
--
Darren
# 2
Thanks Darren.
Agreed: The 80 character execution string comes from /proc/<pid>/psinfo, readable by all, and the environment and full command line come from the address space of the process /proc/<pid>/as, readable by that process or root only.
/usr/ucb/ps works out who you are and invokes /usr/ucb/sparcv9/ps.
The patch removes setuid on /usr/ucb/sparcv9/ps, and presumably allows it to cope with the fact it will now be able to read /proc/<pid>/psinfo but not /proc/<pid>/as (previously it was sure to be able to read both).
I think Linux provides /proc/<pid>/cmdline and so is able to offer the command line without necessarily giving access to the full address space, including the environment.
It does this by giving the address space and command line entries in the proc filesystem different file permissions.
Solaris could do the same.
The proc filesystem already allows one process to dip into the memory of another (via /proc/<pid>/as), this is a variation this existing theme.
ps could read /proc/<pid>/cmdline if present, else fall back to the current behaviour.
I understand this is more work/change than went into the current patch.
You could make /usr/ucb/ps setuid if you wanted to
allow non-privileged users access to that data.
Err, no, that would mean that everyone would see roots process list rather than their own, if they didn't ask for all processes.
You mean make /usr/ucb/sparcv9/ps setuid, and indeed, as explained above, that effectively undoes the patch, to the point that the environment as well as the full command line becomes available again.
However, you could file a bug or RFE on
bugs.opensolaris.com and discuss it with others.
Could do.
Given that 'pargs' exists, I don't think a lot of
folks are going to want to change the current
behavior.
My Solaris 8 box doesn't seem to have pargs.
Not sure I want to revisit my (and vendor) scripts that /usr/ucb/ps either.
{{{ Andy
# 3
I just stumbled on http://www.softpanorama.org/Solaris/oss_for_solaris.shtml.
In a section titled "ps", it talks about the 80 character limitation, mentions they feel it is fixable, and say
"Until then all of us are stuck using the "deprecated" "/usr/ucb/ps axww" approach to do what we need.".
IMHO the only real reason /usr/ucb/ps is/was useful today is to get at the full argument string, not so much to maintain command line argument compatability.
{{{ Andy
