full-disclosure - Re: Mac OS X "ps(3)" and "top(3)" truncate output

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 11 May 2007 11:40:38 -0400
From: Valdis.Kletnieks@...edu
To: matador matador <m4t4d00r@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Mac OS X "ps(3)" and "top(3)" truncate output

On Fri, 11 May 2007 17:18:20 +0200, matador matador said:

> rfc-1918:~ xxx$ ps aux > ps_output

> we can see that "ps" doesn't print completely the path.

ps auxw will do so.  If that isn't enough, try 'ps auxewwwwww'

> rfc-1918:~ xxx$ cat ps_output | grep iTunes

This wins an award for 'Pointless use of cat'.  Preferred:

% grep iTunes ps_output
% grep iTunes <  ps_output

Or don't bother with the intermediate file at all:

% ps auxw | grep 'i[T]unes'

(Yes, the [] are intentional, and experienced Unix/Linux users know why :)

(As an added bonus, on some systems /bin/ps will notice that it's going to
a pipe, and automagically disable the 'trim to terminal width' code for you,
totally obviating the issue. A quick check shows Linux does, Solaris and an
older AIX box don't.)

> These issues open an user-space rootkit scenario.

No scenario that hasn't been there for literally a quarter of a century already,
the 'w' flag was added *decades* ago for basically this reason....

Content of type "application/pgp-signature" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/