Re: Jdk13/14 still hangs in 4.8 Prerelease. Outstanding Fix need (fwd)
Hi, At 22:01 25/2/03, Robert Watson wrote: [...] I would oppose simply enabling the current CANSIGNAL check -- it has serious problems. On the other hand, putting in a refined check sounds reasonable and I'd be happy to review such a patch. Although the code from 5.x won't instantly work with 4.x without substantial modification, it might make a good starting point. OK, so what's the score with the patch at the end of the kern/40611 audit trail? Thanks -- Bob Bishop +44 (0)118 977 4017 [EMAIL PROTECTED] fax +44 (0)118 989 4254 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Jdk13/14 still hangs in 4.8 Prerelease. Outstanding Fix need
On 26-Feb-2003 Bob Bishop wrote: Hi, At 22:01 25/2/03, Robert Watson wrote: [...] I would oppose simply enabling the current CANSIGNAL check -- it has serious problems. On the other hand, putting in a refined check sounds reasonable and I'd be happy to review such a patch. Although the code from 5.x won't instantly work with 4.x without substantial modification, it might make a good starting point. OK, so what's the score with the patch at the end of the kern/40611 audit trail? Thanks I think that we would prefer that someone fix the CANSIGNAL check as Robert desires and then enable it. The patch in the PR basically allows one to get information about any process even if you aren't root, so I think that may be a bad idea. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Jdk13/14 still hangs in 4.8 Prerelease. Outstanding Fix need
On 25-Feb-2003 Bob Bishop wrote: At 14:56 25/2/03, Murray Stokely wrote: This has been a problem for years and it affects other Linux appications such as LabView. There is some commented out code in linux_sched_getscheduler() function that provides the proper functionality. It's unclear to me why the code was commented out in the first place, but it would be really nice to get that resolved once and for all. According to kern/40611, the problem is in posix4/p1003_1b.c not in the linux wrapper. The updated patch in the PR audit trail seems to work. There is a much simpler patch one can do: Index: p1003_1b.c === RCS file: /usr/cvs/src/sys/posix4/p1003_1b.c,v retrieving revision 1.5.2.1 diff -u -r1.5.2.1 p1003_1b.c --- p1003_1b.c 3 Aug 2000 01:09:59 - 1.5.2.1 +++ p1003_1b.c 25 Feb 2003 16:17:55 - @@ -62,7 +62,7 @@ * only root can do this. */ -#if 0 +#if 1 /* * This is stolen from CANSIGNAL in kern_sig: * Basically, it changes p31b_proc() to not always return an error for non-root. If rwaston@ signs off on the security implications (should be minimal, basically means that you can change your own scheduling params and can change the params of other processes you own) then I would prefer this patch. I don't know why the check was turned off. The entire #if 0 / #else / #endif seems to have been around since revision 1.1. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Jdk13/14 still hangs in 4.8 Prerelease. Outstanding Fix need
On Tue, Feb 25, 2003 at 11:20:34AM -0500, John Baldwin wrote: Basically, it changes p31b_proc() to not always return an error for non-root. If rwaston@ signs off on the security implications (should be minimal, basically means that you can change your own scheduling params and can change the params of other processes you own) then I would prefer this patch. Yes this is the one I was thinking about when I said the commented out code. I've run a kernel with this patch for months, and I didn't see any problems with it in my (unqualified) review. ;) - Murray pgp0.pgp Description: PGP signature
Re: Jdk13/14 still hangs in 4.8 Prerelease. Outstanding Fix need (fwd)
Per Martin's request, I'm forwarding this response to the broader group involved in this thread. Basically, I think broadening the scope of processes permitted to make the scheduler call is fine, but you don't want to use the CANSIGNAL() code that's currently present for several reasons. The simplist solution might be to only allow the scheduler change if the requesting process is targetting itself. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories -- Forwarded message -- Date: Tue, 25 Feb 2003 12:53:53 -0500 (EST) From: Robert Watson [EMAIL PROTECTED] To: Martin Blapp [EMAIL PROTECTED] Subject: Re: Jdk13/14 still hangs in 4.8 Prerelease. Outstanding Fix need (fwd) On Tue, 25 Feb 2003, Martin Blapp wrote: Basically, it changes p31b_proc() to not always return an error for non-root. If rwaston@ signs off on the security implications (should be minimal, basically means that you can change your own scheduling params and can change the params of other processes you own) then I would prefer this patch. Hmm. I think the check there is a bit on the unsafe side, that could be why it was disabled. Basically, it permits the scheduler change in the following four circumstances: (0) Superuser always wins (1) Subject real uid is object real uid E.g., any process I should randomly start or own (2) Subject effective uid is object real uid If a tool is temporarily switched to my uid to exercise my privileges, sounds OK. (3) Subject real uid is object effective uid (uh oh) (4) Subject effective uid is object effective uid (uh oh) The reason (3) and (4) are problems is that they affect daemons temporarily switching to a user's privileges to carry out a task -- such as mail delivery, or a userland NFS server or the like. It could be that these are poor handling of the loopback process case, wherein a process can always modify its own scheduling. Take a look at p_cansched() in 5.x for a bit more what I think the check should be. In summary, the rules are: (0) You can always reschedule the current process. (1) If you're in a different jail, deny. (2) Optionally call out to MAC. (3) If the seeotheruids support says you can't see the other process, you can't reschedule it either, regardless of uids. (4) If the real uids are the same, it's OK -- i.e., any arbitrary shell process (setuid or otherwise). (5) If the subject effective uid is the same as the object real uid -- if temporarily adopting a user's privileges, we can reschedule the processes they own. (6) Superuser always wins (subject to 0, 1, 2, 3). (7) Deny I don't know why the check was turned off. The entire #if 0 / #else / #endif seems to have been around since revision 1.1. It's probably because whoever wrote it realized that it was moderately suspect. I would oppose simply enabling the current CANSIGNAL check -- it has serious problems. On the other hand, putting in a refined check sounds reasonable and I'd be happy to review such a patch. Although the code from 5.x won't instantly work with 4.x without substantial modification, it might make a good starting point. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
