Date: Mon, 24 Mar 2003 22:13:35 -0800 (PST) From: Robert Watson <rwatson@FreeBSD.org> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/posix4 p1003_1b.c Message-ID: <200303250613.h2P6DZDB011306@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
rwatson 2003/03/24 22:13:35 PST
FreeBSD src repository
Modified files: (Branch: RELENG_4)
sys/posix4 p1003_1b.c
Log:
When the p1003_1b support for monitoring with and interfering with
the system scheduler was committed, access to these facilities was
limited to the root user (for unclear reasons, perhaps lack of
understanding about the potential impact of the interfacs on
system operation, or due to bugs). However, the JDK requires the
ability to monitor scheduler parameters and selection for
linux-threaded processes; a return of EPERM causes some applications
to fail as a result (in particular, the JDK). In 5.x-CURRENT,
we've replaced the access control with centralized access control
primitives, giving these interfaces controls similar to those
applied for rtprio(), setpriority(), etc, resulting in uniform
enforcement.
In order to enable proper JDK operation for 4.8-RELEASE, work around
the lack of proper access control by permitting the use of two
system calls: sched_getparam() and sched_getscheduler(), for non-root
processes when the call is made on the current process (either using
a 0 pid argument, or curproc->p_pid). While we're here, fix a
bug that caused the result of the call to be returned in the
target process, not in the subject process (ouch!), but that
previously only affected root-owned processes. These fixes are
deemed to be the lowest impact approachin the release; a backport
of the 5.x-CURRENT access control primitives might also be appropriate
in a non-release scenario. This fix doesn't permit the calls to
succeed on other linuxthreads in the same linuxthread process, but
despite those failures the JDK appears to operate properly, so
we've opted not to broaden the scope to permit the p->p_leader ==
targetp->p_leader case at this point.
The "wrong process" return value may apply to other system calls
due to overloading of the subject process pointer with the target
process, but doesn't currently affect non-root processes (and is
fairly uncommon as usually processes are interested in frobbing their
own scheduler details, not other processes, hence it not really
showing up before). This should be fixed in the post 4.8-RELEASE
time frame. These bugs should not be present in 5.x due to
process-locking and security-related changes made in that branch
well prior to 5.0-RELEASE.
Submitted by: mbr (collaborative)
Approved by: re (murray)
Revision Changes Path
1.5.2.2 +21 -10 src/sys/posix4/p1003_1b.c
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200303250613.h2P6DZDB011306>