docs: renice(1): Rework discussion of unprivileged users,

The BUGS section describing the limitations on what an unprivileged
user may do to the nice value is outdated, given the kernel changes
that added RLIMIT_NICE in Linux 2.6.12. So, remove that text.

The revised details for modern Linux were partially covered in NOTES,
but there were also inaccuracies there (and the use of the word
"monotonically" was unneeded). In particular, the point is that
unprivileged users can only increase the nice value. There is no
restriction particular to the range 0..+19. So, for example, the
following scenario is possible:

1. Superuser sets the nice value of an unprivileged user's
   process to -20.
2. The unprivileged user can now renice that process to (say) -10.

Signed-off-by: Michael Kerrisk <mtk.man-pages@gmail.com>
Signed-off-by: Karel Zak <kzak@redhat.com>

diff --git a/sys-utils/renice.1 b/sys-utils/renice.1
index a407b7000db6986d83f74b586cc1e2197ce14009..36e6a5579f4393069bbb3129924f41dc97c8a17e 100644 (file)
--- a/sys-utils/renice.1
+++ b/sys-utils/renice.1
@@ -84,10 +84,16 @@ PIDs 987 and 32, plus all processes owned by the users daemon and root:
 .B "       renice" +1 987 -u daemon root -p 32
 .SH NOTES
 Users other than the superuser may only alter the priority of processes they
-own, and can only monotonically increase their ``nice value'' (for security
-reasons) within the range 0 to 19,
-unless a nice resource limit is set (Linux 2.6.12 and higher).  The
-superuser may alter the priority of any process and set the priority to any
+own.  Furthermore, an unprivileged user can only
+.I increase
+the ``nice value'' (i.e., choose a lower priority)
+and such changes are irreversible unless (since Linux 2.6.12)
+the user has a suitable ``nice'' resource limit (see
+.BR ulimit (1)
+and
+.BR getrlimit (2)).
+
+The superuser may alter the priority of any process and set the priority to any
 value in the range \-20 to 19.
 Useful priorities are: 19 (the affected processes will run only when nothing
 else in the system wants to), 0 (the ``base'' scheduling priority), anything
@@ -101,9 +107,6 @@ to map user names to user IDs
 .BR getpriority (2),
 .BR setpriority (2)
 .SH BUGS
-Non-superusers cannot increase scheduling priorities of their own processes,
-even if they were the ones that decreased the priorities in the first place.
-.PP
 The Linux kernel (at least version 2.0.0) and linux libc (at least version
 5.2.18) does not agree entirely on what the specifics of the systemcall
 interface to set nice values is.  Thus causes renice to report bogus previous