Subject: Re: kern/35226: Problems with permissions in /usr/pkg/emul/linux/proc .
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: Christos Zoulas <christos@zoulas.com>
List: netbsd-bugs
Date: 12/24/2006 17:10:03
The following reply was made to PR kern/35226; it has been noted by GNATS.

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, kern-bug-people@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
	jfranz@bsdprojects.net
Cc: 
Subject: Re: kern/35226: Problems with permissions in /usr/pkg/emul/linux/proc .
Date: Sun, 24 Dec 2006 12:09:51 -0500

 On Dec 24,  2:45pm, elad@NetBSD.org (Elad Efrat) wrote:
 -- Subject: Re: kern/35226: Problems with permissions in /usr/pkg/emul/linux/
 
 |  >  that's a known issue that I already have a fix for. I'm not sure what
 |  >  kind of semantics we want to have in procfs (ie., exclude cpuinfo from
 |  >  the kauth check, or do that depending on uio_rw, or put it in the
 |  >  secmodel) so I'm holding it for now.
 
 Well, the code before was:
 
 
         /*
          * Do not allow init to be modified while in secure mode; it
          * could be duped into changing the security level.
          */
         if (uio->uio_rw == UIO_WRITE && p == initproc && securelevel > -1)
                 return EPERM;
 
 
 Which always allowed reads and forbad writes for init when securelevel > -1
 This is not what the new code is doing is it, although the comment has remained
 the same? I did not look at the procfs authorize code, but if it is doing
 what the above if statement is doing, you should not need the case statement.
 
 christos