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