Re: EPERM for CTLFLAG_ANYBODY sysctl.
Re: EPERM for CTLFLAG_ANYBODY sysctl.
- Subject: Re: EPERM for CTLFLAG_ANYBODY sysctl.
- From: Terry Lambert <email@hidden>
- Date: Wed, 20 Aug 2008 10:02:33 -0700
On Aug 20, 2008, at 5:02 AM, Maxim Zhuravlev
<email@hidden> wrote:
Hi, all.
Could you give me a hint, why do I get an EPERM error from
sysctlbyname() for a write attempt to a sysctl of a type:
SYSCTL_PROC (
_kern,
OID_AUTO,
my_name,
CTLTYPE_OPAQUE | CTLFLAG_WR | CTLFLAG_ANYBODY | CTLFLAG_KERN,
0,
0,
sysctl_handler, // my handler
"S",
""
);
The sysctl is registered from within a kext.
I get EPERM error for non-root processes, while it works fine for root
processes.
Shouldn't CTLFLAG_ANYBODY flag make it possible for non-root processes
to write to the sysctl?
You are getting bit by using "sysctl" instead of "newsysctl"
declarations and/or using a different communications mechanism.
The OIDs privilege check is done at the root node of the sysctl rather
than at the leaf nodes for most of the OID space.
Its generally best if you use some other mechanism if you need to
communicate with your KEXT from non-root processes. Sockets are one
way, ioctl() down to the exported device node after you open it is
another.
Leopard supports locking at the leaf nodes for things not directly in
the static OID space, but the privilege check will still be at the
root unless you stay away from the static space and use sysctlbyname
(), and all intermediate nodes all the way to the root are flagged for
leaf locking.
Eventually I someday hope to kill off sysctl by OID entirely, since
people abuse the tail end of the OID space to pass around arbitrary
data, like addresses. As you can imagine, truncating a 64 bit address
to 32 bits and jamming it in an integer tends to make 64 bit processes
crash.
My recommendation would be avoid kern., hw., and other static OID
values entirely, and avoid sysctl itself if at all possible; if not,
then use auto OIDs flagged for leaf locking and make sure you actually
implement appropriate locking.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden