control: reassign -1 procps 2:4.0.3-1
control: retitle -1 pgrep: signal handler matching breaks argument parsing
thanks
Hi Adrian,
Thanks for the report!
On 11:07 Wed 22 Feb , Adrian Bunk wrote:
>
> # Check with a single, known unused user-id
> #
> # We use "-1" here, which is not a valid user-id, so it's
> # guaranteed that it's unused.
> uid = uidpool.RequestUnusedUid(set([-1]))
> self.assertEqualValues(uid.GetUid(), -1)
>
>
> "pgrep -u -1" is now rejected by procps.
This is a (presumably) unintentional side effect of procps commit
866abacf ("pgrep: Support matching on the presence of a userspace signal
handler")[1], which added the same "-<signal>" argument of pkill to pgrep.
With this change, pgrep parses the numerical options in the same way as pkill:
it uses getopt_long() for most options, but it performs a manual argv
scan[2] specifically to find signal-like options (e.g. -1, -88, -kill,
etc.).
The result is that anything that looks like a signal option, but is
passed as an argument to any of the other options, is removed early on
from the argument list, causing a subsequent call to getopt_long() to
fail if the original option takes a mandatory argument:
$ pgrep -u -93
pgrep: option requires an argument -- 'u'
...
$ pgrep -d -2
pgrep: option requires an argument -- 'd'
...
$ pgrep -u -hup
pgrep: option requires an argument -- 'u'
...
We could probably question the usefulness of negative UID/PID/SIDs
here, on the other hand this had been working for at least 15 years
before breaking in a minor release. I'm reassigning this bug to procps
for further discussion.
Cheers,
Apollon
[1]
https://gitlab.com/procps-ng/procps/-/commit/866abacf8805a74fb7c59cae1f64963e0a540b14
[2]
https://gitlab.com/procps-ng/procps/-/blob/806eb270f217ff7e1e745c7bda2b002b5be74be4/src/pgrep.c#L798
