Commit Graph

112 Commits

Author SHA1 Message Date
ed
9975595b9b pgrep.c: simplifying uptime call 2020-05-17 21:53:39 +10:00
ed
79a4eb6128 pgrep.c: Replacing seconds_since_boot with uptime as suggested by Craig Small 2020-05-17 21:53:39 +10:00
ed
41b9e62be7 pgrep.c: change to allow 'older than' style selection
pgrep.1: man page addition for above selection
Makefile.am: addition of global.c to include sections since boot in pgrep.
2020-05-17 21:53:36 +10:00
Arun Chandrasekaran
7d55409b82 pgrep: use sigqueue to pass value with the signal.
Based on the command line option, use 'sigqueue'
instead of 'kill' to pass the integer value with
the signal.

References:
 procps-ng/procps!32

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2020-04-25 13:15:06 +10:00
Todd Lewis
c833a62418 Fix user and group name to number conversion for uid/gid above 2^31. 2020-04-24 17:28:42 +10:00
Craig Small
bb96fc4295 pgrep: check sanity of SC_ARG_MAX
A kernel change means we cannot trust what sysconf(SC_ARG_MAX)
returns. We clamp it so its more than 4096 and less than 128*1024
which is what findutils does.

References:
 procps-ng/procps#152
 https://git.savannah.gnu.org/cgit/findutils.git/tree/lib/buildcmd.c#n535
 https://lwn.net/Articles/727862/
2020-01-05 15:05:55 +11:00
Clay Baenziger
f9e56d3c66 pgrep: Use POSIX _SC_ARG_MAX for maximum full command line length 2019-09-21 16:39:13 +10:00
Craig Small
2fa3bb0669 misc: update for pgrep runstate
Added some minor fixes and notes
2019-03-05 07:59:48 +11:00
ed
e13eb8b75e pgrep.c: Match based on process run state for issue 109 2019-03-05 07:53:59 +11:00
Craig Small
c32ab58b94 pgrep: Remove >15 warning
As comm length can be longer than 15 characters with newer kernels, it
doesn't make sense to have a warning when you make the match string
longer than this.

As a side-effect, it removes the false-positive you got when you used
long regex matches (see issue #92 )

References:
 commit 2cfdbbe897
 procps-ng/procps#92
2018-05-19 08:14:06 +10:00
Qualys Security Advisory
b51ca2a1f8 pgrep: Prevent a potential stack-based buffer overflow.
This is one of the worst issues that we found: if the strlen() of one of
the cmdline arguments is greater than INT_MAX (it is possible), then the
"int bytes" could wrap around completely, back to a very large positive
int, and the next strncat() would be called with a huge number of
destination bytes (a stack-based buffer overflow).

Fortunately, every distribution that we checked compiles its procps
utilities with FORTIFY, and the fortified strncat() detects and aborts
the buffer overflow before it occurs.

This patch also fixes a secondary issue: the old "--bytes;" meant that
cmdline[sizeof (cmdline) - 2] was never written to if the while loop was
never entered; in the example below, "ff" is the uninitialized byte:

((exec -ca `python3 -c 'print("A" * 131000)'` /usr/bin/cat < /dev/zero) | sleep 60) &
pgrep -a -P "$!" 2>/dev/null | hexdump -C
00000000  31 32 34 36 30 20 41 41  41 41 41 41 41 41 41 41  |12460 AAAAAAAAAA|
00000010  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
*
00001000  41 41 41 41 ff 0a 31 32  34 36 32 20 73 6c 65 65  |AAAA..12462 slee|
00001010  70 20 36 30 0a                                    |p 60.|
2018-05-19 07:32:21 +10:00
Qualys Security Advisory
40c4254318 pgrep: Always null-terminate the cmd*[] buffers.
Otherwise, man strncpy: "If there is no null byte among the first n
bytes of src, the string placed in dest will not be null-terminated."
2018-05-19 07:32:21 +10:00
Qualys Security Advisory
35f58d8a3e pgrep: Initialize the cmd*[] stack buffers.
Otherwise (for example), if the (undocumented) opt_echo is set, but not
opt_long, and not opt_longlong, and not opt_pattern, there is a call to
xstrdup(cmdoutput) but cmdoutput was never initialized:

sleep 60 & echo "$!" > pidfile
env -i LD_DEBUG=`perl -e 'print "A" x 131000'` pkill -e -c -F pidfile | xxd
...
000001c0: 4141 4141 4141 4141 4141 4141 4141 4141  AAAAAAAAAAAAAAAA
000001d0: 4141 4141 4141 4141 fcd4 e6bd e47f 206b  AAAAAAAA...... k
000001e0: 696c 6c65 6420 2870 6964 2031 3230 3931  illed (pid 12091
000001f0: 290a 310a                                ).1.
[1]+  Terminated              sleep 60

(the LD_DEBUG is just a trick to fill the initial stack with non-null
bytes, to show that there is uninitialized data from the stack in the
output; here, an address "fcd4 e6bd e47f")
2018-05-19 07:32:21 +10:00
Qualys Security Advisory
d0d902f089 pgrep: Simplify the match_*() functions. 2018-05-19 07:32:21 +10:00
Qualys Security Advisory
5d2b44eaf6 pgrep: Replace buf+1 with buf in read_pidfile().
Unless we missed something, this makes it unnecessarily difficult to
read/audit.
2018-05-19 07:32:21 +10:00
Qualys Security Advisory
c1dbd41d2b pgrep: Replace ints with longs in strict_atol().
atol() means long, and value points to a long.
2018-05-19 07:32:21 +10:00
Qualys Security Advisory
4ea5b22d62 pgrep: Prevent integer overflow of list size.
Not exploitable (not under an attacker's control), but still a potential
non-security problem. Copied, fixed, and used the grow_size() macro from
pidof.c.
2018-05-19 07:32:21 +10:00
Qualys Security Advisory
657053f5d0 pgrep: Do not memleak the contents of proc_t.
memset()ing task and subtask inside their loops prevents free_acquired()
(in readproc() and readtask()) from free()ing their contents (especially
cmdline and environ).

Our solution is not perfect, because we still memleak the very last
cmdline/environ, but select_procs() is called only once, so this is not
as bad as it sounds.

It would be better to leave subtask in its block and call
free_acquired() after the loop, but this function is static (not
exported).

The only other solution is to use freeproc(), but this means replacing
the stack task/subtask with xcalloc()s, thus changing a lot of code in
pgrep.c (to pointer accesses).

Hence this imperfect solution for now.
2018-05-19 07:32:21 +10:00
Craig Small
791cb72d32 Revert "Support running with child namespaces"
This reverts commit dcb6914f11.

This commit broke a lot of scripts that were expecting to see all
programs. See #91
2018-04-10 21:14:01 +10:00
Craig Small
0b488c7f5c pgrep: Don't segfault with no match
If pgrep is run with a non-program name match and there are
no matches, it segfaults.

The testsuite thinks zero bytes sent, and zero bytes sent
because the program crashed is the same :/

References:
 commit 1aacf4af7f
 https://bugs.debian.org/894917

Signed-off-by: Craig Small <csmall@enc.com.au>
2018-04-06 23:00:29 +10:00
Debabrata Banerjee
dcb6914f11 Support running with child namespaces
By default pgrep/pkill should not kill processes in a namespace it is not
part of. If this is allowed, it allows callers to break namespaces they did
not expect to affect, requiring rewrite of all callers to fix.

So by default, we should work in the current namespace. If --ns 0 is
specified, they we look at all namespaces, and if any other pid is specified
we continue to look in only that namespace.

Signed-off-by: Debabrata Banerjee <dbanerje@akamai.com>
2018-03-03 17:59:18 +11:00
Craig Small
625d0809da pkill: Return 0 if successfully killed process
Original report:
When trying kill a process with insufficient privileges (see blow),
pkill displays the error message “... failed: Operation not permitted”,
but returns 0. Surely it should return 3?

$ pkill syslogd ; echo $?
pkill: killing pid 373 failed: Operation not permitted
0

Return value 0 means one of more things matched. For a pgrep (which
shares code with pkill) this makes sense, there was a match. It seems
wrong for pkill to return 0 when it in fact could not do what you told
it to.  However return value 3 means a fatal error and it's not fatal.

Looking at other programs when trying to kill things it cannot kill.
shell kill returns 1, procps kill returns 1, killall returns 1, skill
returns 0 (and says it was successful!, ah well poor old skill)

The consensus seems to be that you return 1 if you cannot kill it, even
if you found it. In other words the return value for both not found and
not able to kill it is the same.

pkill only returns 0 if something was killed. This means we found a
match AND the kill() system call worked too.

References:
 https://bugs.debian.org/852758

Signed-off-by: Craig Small <csmall@enc.com.au>
2017-02-04 11:44:01 +11:00
Jan Rybar
1aacf4af7f pgrep: warning about 15+ chars name only if zero matches found
This avoids situations where longer regex which matches short-named proc is used.
Test for pgrep updated.
2017-01-02 14:50:22 +01:00
Craig Small
24fd2605c5 pgrep: Fix off by one error in line check
There is now a warning if your command is longer than 15 characters
and therefore can never match. Except it was checking for more than
16 characters.

Adjusted this and added a test case.

References:
 !25
 commit 8e8835b2ee
2016-09-11 10:11:25 +10:00
Jan Rybar
4a7f9fca14 pgrep - adds warning that pattern exceeds 15 chars without '-f' option 2016-09-06 18:41:56 +02:00
Filipe Brandenburger
9646f7cba4 pkill: reject -signal number with trailing garbage
This commit prevents pkill from accepting something like `-1garbage` as
a SIGHUP. The previous code was using atoi() which does not check for
trailing garbage and would parse the above as 1.

Handling numeric signals in signal_option() is not really necessary,
since signal_name_to_number() will recognize numeric signals and parse
them properly using strtol() and checking for trailing garbage. It also
checks that the numeric signals are in the proper range. So all we need
to do is remove the buggy numeric signal handling here.

Tested with `pkill -1garbage sleep`, after this patch it will complain
that "1" is not a valid option, which is the expected.

Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-07-07 10:39:49 -07:00
Craig Small
505f257a8c library: remove procps_version functions
It doesn't make any sense to have the binary version strings
embedded into the library. The version strings are defined
already either in the Makefile or in include/c.h
2015-06-18 22:37:24 +10:00
Filipe Brandenburger
e566680254 pgrep: prevent buffer overflow in opts
Recent commit 9742c74e7c ("pgrep: Enable case-insensitive process matching")
caused the "opts" string to overflow the show 32-character space allocated for
it.

Bump it up to 64 bytes, which should be enough even if more options are added.

Tested: Running ./pgrep stopped crashing and `make check` passed.

Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-13 22:04:58 +10:00
William Orr
9742c74e7c pgrep: Enable case-insensitive process matching
FreeBSD has case-insensitive matching of processes in pgrep and
pkill, which can be super-useful. This patch uncomments and
documents the code needed to make this work.

Signed-off-by: Craig Small <csmall@enc.com.au>
2015-05-10 17:42:09 +10:00
Vadim Kaushan
6ed8cf3444 pgrep: Off by one in realloc in option handling
The loop that parses options has a of by one bug where the realloc
adds one byte, instead of one list element.  This is exposed when
you try things like:
  pgrep -t,,,,

Signed-off-by: Craig Small <csmall@enc.com.au>
2015-04-03 18:17:08 +11:00
Eero Häkkinen
0f649e2cd2 pgrep: avoid SEGV when lightweight and list-full options are used together
do not segfault
2014-09-06 00:35:16 +03:00
Beni Cherniavsky-Paskin
b4951bfea3 Add -a/--list-full to --help output. 2014-08-19 21:05:30 +02:00
Jaromir Capik
4ba9ff5c0d pgrep: Fixing regression in exitcodes
The pgrep usage() rework commit from 26-Sep-2011 introduced
a regression in exitcodes and the pgrep tool now returns
EXIT_FAILURE (1) or even EXIT_SUCCESS (0) instead
of the documented EXIT_USAGE (2). This commit fixes
the usage() so that the exitcodes match the manual.
2014-07-02 17:42:08 +02:00
Craig Small
8e7ef322e2 Update help files
Benno Schulenberg suggested some changes to the help messages
to provide some consistency and clarity for both the users and
translators of procps.

The test needed to be updated as the pmap output changed too.

Signed-off-by: Craig Small <csmall@enc.com.au>
2014-02-02 18:13:01 +11:00
Craig Small
ca99070012 Merge branch 'merge-requests/23' 2014-01-30 22:12:28 +11:00
Elliott Forney
6f1c04259d pgrep fails to show full command line with -au
pgrep does not show the full command line when the -a and -u flags are
combined. The -a flag is ignored when the -u flag is used as well.

In addition, the supplied patch by Elliot did not fix the problem
when invert flag ( -v ) was used; a very small tweak to the patch
fixed this problem as well. This problem existed before.

Signed-off-by: Craig Small <csmall@enc.com.au>
2014-01-30 21:36:26 +11:00
Jaromir Capik
69de8db3e2 pgrep: Fixing memory leak in do_regcomp() 2014-01-02 18:39:27 +01:00
Ryan Cox
c304ffa994 fail on null string for arguments 2013-10-28 21:05:35 -06:00
Craig Small
6437aa08d4 Update options to single strings
To assist the translators, each option is a separate string.
This means if we add/change/delete an option the remaining ones
will just keep working and only the impacted option needs some
translation work on it.
2013-10-11 10:07:10 +11:00
Jim Warner
e6bbcdb492 misc: correct additional errors from merge request #13
Additional errors resulting from merge request #13 are
being addressed in this commit. They involve two cases
of trailing whitespace and one xwarnx printf type arg.

Reference(s):
http://gitorious.org/procps/procps/merge_requests/13
. earlier build-sys fix
commit e2242cb943
. original merge
commit dd6f24dbed

Signed-off-by: Jim Warner <james.warner@comcast.net>
2013-09-17 20:27:02 +02:00
Craig Small
dd6f24dbed Merge commit 'refs/merge-requests/13' of git://gitorious.org/procps/procps into merge-requests/13
Conflicts:
	pgrep.c
	ps/output.c
	ps/ps.1
2013-09-11 21:34:05 +10:00
Aristeu Rozanski
de7b3b9222 pgrep: introduce support for namespaces
A PID should be specified with --ns:
	$ pgrep --ns 12345
which will only match the processes which belong to to the same 6
namespaces. It is also possible to specify which namespaces to test:
	$ pgrep --ns 12345 --nslist mnt,net,ipc
which will match processes that belong to the same mount, network and
IPC namespaces as PID 12345.

Signed-off-by: Aristeu Rozanski <arozansk@redhat.com>
2013-04-16 15:05:31 -04:00
Jim Warner
7888f6a679 miscellaneous: clean up trailing whitespace once again
An earlier commit attempted to cleanse our environment
of all useless trailing whitespace. But the effort did
not catch 'empty' lines with a single space before ^J.

This commit hopefully finishes off the earlier effort.
In the meantime, let's pray that contributors' editors
are configured so that such wasted crap is disallowed!

Reference(s):
commit fe75e26ab6

Signed-off-by: Jim Warner <james.warner@comcast.net>
2013-04-07 18:05:01 +10:00
Rainer Müller
042776e04c configure: check for program_invocation_name
For portabiliy, check for program_invocation_name during configure and
define HAVE_PROGRAM_INVOCATION_NAME accordingly. Use of this symbol is
now enclosed with the appropriate #ifdef block.

The symbol program_invocation_name is only used for error message
handling using error(), so it's safe to omit this if it is not
available.
2013-03-20 16:32:06 +01:00
Roberto Polli
aa5a19620b support for listing thread ids (useful with iotop) 2013-03-18 11:58:47 +01:00
Jim Warner
fe75e26ab6 miscellaneous: clean up trailing whitespace throughout
The entire tree's polluted with inappropriate trailing
whitespace. This commit rids our environment of all of
those useless keystrokes. Unfortunately, it sure ain't
a permanent solution and requires every contributor to
instruct their editor(s) to prevent or eliminate them.

Plus it's strongly recommended we all insert something
like what's shown below to our '.gitconfig' file so as
to provide at least some warnings when we try to apply
any patches (git am) that do contain the #@!%& things!

References(s):
~/.gitconfig excerpt ---------------------------------
[core]
  whitespace = trailing-space, space-before-tab, blank-at-eof
[apply]
  whitespace = warn
--------------------------------- ~/.gitconfig excerpt

Signed-off-by: Jim Warner <james.warner@comcast.net>
2013-03-14 12:36:47 +01:00
static.vortex@gmx.com
cff3960c4a pgrep: Documentation fixes
Minor fixes to the help output and manpage of pgrep.
2013-02-18 21:41:31 +11:00
Craig Small
ce95dd53eb Add -c count option to pkill
Possibly by a side-effect but pkill -c option used to work which would
print the number of killed processes.  This small change restores this
functionality.

Bug-Debian: http://bugs.debian.org/693783

Signed-off-by: Craig Small <csmall@enc.com.au>
2012-11-21 22:11:17 +11:00
Sami Kerola
9ba7f3abdb pgrep: fix compiler warnings
pgrep.c:195:12: warning: 'fcntl_lock' defined but not used [-Wunused-function]
pgrep.c:575:5: warning: no previous declaration for 'signal_option' [-Wmissing-declarations]

Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2012-11-06 22:27:48 +11:00
Craig Small
9a60202b81 pgrep delimeter to delimiter
pgrep used delimiter and delimeter, the correct spelling is delimiter.
Thanks to Alexander Kobel for the heads-up.

Signed-off-by: Craig Small <csmall@enc.com.au>
2012-10-11 21:34:50 +11:00