[rhn-users] Re: [Bug 167723] 'renice(1)' documentation allows 'renice -n 4 -p $$' but resets PID 4 nice value on i386 FC4 load on i686

Wed Sep 21 17:01:20 UTC 2005

I have already replied to this twice, and I have already set the 
severity back to severe/high/security.

My login is not geting me in at this point again (NOT THE FAULT OF RED HAT;
I have had security spoofs against me for a long time).

Changing the priority of a system service process unintentionally is of 
the highest performance and security flaw:  this bug does that.

Read below:  a snarf od the web pages, unfortunately with details left out:
the snarf does NOT get the full text in the _boxes_, ... thiu smaking it 
hard
to reduplicate OUTDSIDE of the form without going through MORE time to 
print and capture it.  time I do no t have.
here is the bug:
----
Alias                           Priority
Product                         Severity
Version                         Status  MODIFIED
Component                       Resolution
OS                      Add CC
Hardware
Reporter        roy a. crabtree
Assigned To     Ivana Varekova

Bug Comments
Opened by roy a. crabtree       on 2005-09-07 12:43 EST         [reply]

 From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) 
Gecko/20050512 Red Hat/1.0.4-1.4.1 Firefox/1.0.4

Description of problem:
Is this a documentation bug,
or a fundamental error in loading
that ought to be trapped on?

   rpm -qif did not find renice.

Ran on one system a cold full FC4 i386 load, then yummed it all on one box;
ran on another an AS i386 update over FC3 latest then yummed it.

Both maintained the same bug.

Documentation has the expected arguments to "renice(1)".

However:

renice -n 4 -p 10968

RESET nice value on PID 4, and did NOT find PID 10968, which DID exist;
which the manual page _and_ info both allow.

renice 4 -p 10968

DID work (finally).

however, a bug in the command line scan of renice will harm other 
processes when running as root; so this is:

A)  A bug in the load sequence where Redhat should force/note an
  architectural (i386/i586/i686/ia64) mismatch or better fit,

B)  An emulation package should be available and default installed/loaded
  for use (either to run emulations, or allow an error trap) when
  a binary package _could_ be made to run correctly, and to stop it
  from doing so when the systems administtrator does not wish to

   Example:  Run a 64 bit application on a 32bit system when no other way;
   run an EMD64 build on an i686 system as a test sequence for a demo
   of the i686 system emulation speeds, or an i386 build on an ia64
   system for older legacy packages, or trap and warn the users NOT to 
do so.

   Or:

C)  'renice(1)' documentation is incorrect and needs fixing AND:

D) 'renice(1)' will incorrectly modify a process priority as root
   if run with the arguments as given on themanual page, or even
   just your own if you mismatch the PID numbers by chance.

    Unfortunately, low PID numbers tend to be critical systems processes;

   so I would regard this last case as SEVERE and CRITICAL.

Sorry for the complex analysis; I do not have the time to run it down by 
rebuilding the systems involved.

the complexity of the "Easy ISO" sequences among many similar but not 
the same architecture and load ocnfiguration packages can easily lead to 
this problem,

ESPECIALLY if a set of load CDs is mislabelled or grabbed incorrectly, 
or the 'yum(1)' repositories are pointed to the wrong channels.

Cheers.

Version-Release number of selected component (if applicable):
latest plus latest patches: coreutils-5.2.1-31.1 over -31.

How reproducible:
Always

Steps to Reproduce:
1. Ran renice to lower a yum download (jerky X11 mouse on a 900 MHz box)
2. Failed with the message no such process 10968
3. Looked up the man and info and saw what I expected
4.  Ran all possible combinations; only:

  renice N -p PID

worked correctly: as root

   renice -n 4 -p 10968

altered the priority or PID 4, and di NOT find PID 10968.

Actual Results:  PID 4 had its nice value changed incorrectly with the 
'-n' flag as described.

reproducible across multiple systems and reboots 100%

Expected Results:  PID 10968 should have its nice value shifted to 4.

Additional info:

I would expect a variant architectural load among similar classes of 
machines, or a variant update among different packagings (FC3 to FC4 WS 
cold, FC3 WS to FC4 AS update) would prompt for _any_ failure 
combination that could occur, and/or make the resulting combination work 
correctly, or be configurable to be trapped as improper (HW emulations) 
from the get go.

  I will note that yum does not catch this type of shift;
  if not validly allowed, it _should_ because _another_
  systems administrator set all this up ...

   and architectural shifts of this type are as old as OS distributions.

The default behavior ought to be, if you load it:

    1) It works.
    2) It tells you if there is a faster way to do it.
    3) it warns you FIRST before doing ANYTHING other than
       EXACTLY the correct load, and
    4) IT TELLS you which way that is, and
    5) IT TELLS YOU when and where and how to get it.

Why allow other combinations?

- Emulations of legacies
- Demonstration of emulaiton speeds
- The user does not have any other load method available
- Demonstration of expertise in tracking down problems
  for training ysstem administrators (evil grin).

Security issue:  A system process can be easily impacted in a way that 
cripples system safeguards if it's priority is altered improperly.

And so forth.

Draw an error propagation tree and you will see what I mean.

A decision table will give you the full set of combinations,
and allow RedHat to come up with a policy analysis table.

Cheers.

PS:  I would have been working for you over the last three years if you 
had hired me.

Comment #1 From Tim Waugh       on 2005-09-07 13:10 EST         [reply]

The renice we ship (as run from the command line you gave) comes from 
util-linux:

$ type renice
renice is /usr/bin/renice
$ rpm -qf /usr/bin/renice
util-linux-2.12p-9.9

Comment #2 From Karel Zak       on 2005-09-08 03:33 EST         [reply]

It's a man page problem. There's two man pages for same thing: renice(1p)
(=POSIX version) and renice(8). The second one is correct. The problem 
is fixed
in FC5 where is no renice.1p. I vote for same solution in FC4 :-)

BTW, see 'man 8 renice':

   renice priority [[-p] pid ...] [[-g] pgrp ...] [[-u] user ...]

Comment #3 From Fedora Updates System   on 2005-09-21 12:30 EST         
[reply]

 From User-Agent: XML-RPC

man-pages-1.67-8 has been pushed for FC4, which should resolve this 
issue.  If these problems are still present in this version, then please 
make note of it in this bug report.

Additional Comments: Add Me to Cc List

Additional Bug Information
Summary
URL
Status Whiteboard
Keywords
Fixed In
Bug 167723 depends on   Show dependency tree
Bug 167723 blocks

Attachment      Status  Type    Created         Size    Actions
Create a New Attachment (proposed patch, testcase, etc.)        View All

External Bugzilla References
Server  ID      Status  Summary         Remove
Add Reference: Location Bug ID
Bug Status Change
Leave as MODIFIED
Change status to
Resolve bug, changing resolution to
         Fixed in version (required for CURRENTRELEASE, otherwise optional)
Resolve bug, mark it as duplicate of bug # (Show Fedora Core/man-pages bugs)
Bug Reassignment
Leave assigned to varekova at redhat.com
Reassign bug to
Reassign bug to owner and QA contact of selected component
---
SINCE CHANGING THE MANUAL PAGE WILL NOT REMOVE THE BUG, AND SINCE THE 
BUG AS PRESENT WILL STIL BE ABLE TO CHANGE THE PRIORITIES OF SYSTEM 
PROCESSES, THE ACTUAL COMMAND LINE ARGUMENT PARSING 9GETOPTS(3C) MUST BE 
FIXED IN RENICE(8).

OTHERWISE A SEVERE SECURITY AND SYSTEM FUNCTIONALITY BREACH IS PRESENT:

ANY ROOT USER USING THE _MODERN_ FORM OF THE COMMAND MAY UNINTENIONALLY 
_LOWER- THE PRIORITY OF A SYSTEM PROCESSS, BREAKING THE SSYTEM SERVICE 
AND CAUSING A SECURITY BREACH BY AT LEAST DENIAL OF SERVICE, POSSIBLY WORSE:

WHAT PROCESSES ARE PIDS 1-19?  CHANGING THEIR NICE VALUE MAY BREAK THE 
SYSTEM SECURITY OR A SYSTEM SERVICE UNDER HIGH CPU LOADINGS BY MAKING 
THE PROCESS STALL, TIMEOUTS OR LATNET BUGS EXPOSED, ETC.

ONLY BY FIXING THE 'RENICE(8)' COMMAND NOT TO HAVE THIS BUG WILL FIX IT.

A DOCUMENTATION CHANGE DOES NOT FIX IT.

bugzilla at redhat.com wrote:

>Please do not reply directly to this email. All additional
>comments should be made in the comments box of this bug report.
>
>Summary: 'renice(1)' documentation allows 'renice -n 4 -p $$' but resets PID 4 nice value on i386 FC4 load on i686
>
>
>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167723
>
>
>
>
>
>------- Additional Comments From updates at fedora.redhat.com  2005-09-21 12:30 EST -------
>From User-Agent: XML-RPC
>
>man-pages-1.67-8 has been pushed for FC4, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.
>
>  
>

-- 
Roy A. Crabtree
UNC '76 gaa.lifer#11086
NC A&T Fort Room 071
1601 East Market Street
Greensboro, NC 27411
336-334-7856/7/8/9 x2249

roy.crabtree <mailto://roy.crabtree@ncat.edu>@(ncat.edu 
<mailto://roy.crabtree@ncat.edu>, alumni.unc.edu 
<roy.crabtree at alumni.unc.edu>, gmail.com <roy.crabtree at gmail.com>)

--
(c) RAC/IP, ARE,PRO,PAST
(Copyright) Roy Andrew Crabtree/In Perpetuity
All Rights/Reserved Explicitly
Public Reuse Only
Profits Always Safe Traded

-------------- next part --------------
A non-text attachment was scrubbed...
Name: roy.crabtree.vcf
Type: text/x-vcard
Size: 348 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/rhn-users/attachments/20050921/8f387c25/attachment.vcf>