Re: Non-priv way to collect job stats under Intel?
Re: Non-priv way to collect job stats under Intel?
- Subject: Re: Non-priv way to collect job stats under Intel?
- From: Erik Paulson <email@hidden>
- Date: Tue, 1 Aug 2006 10:18:39 -0500
On Tue, Aug 01, 2006 at 07:37:17AM -0400, Jeffrey Johnson wrote:
> >
> >If you want to get your current code to work, the recommended way to
> >do this is to factor out the stuff that has to run privileged into a
> >separate setuid root tool.
<...>
>
> Thanks, but this seems like overkill just to get CPU stats for processes we own.
>
> We don't require any authorization dialogs anywhere (drag across install) and some of our customers
> are in some, ah, slighly paranoid environments where a third party SUID-root tool would put us at a
> disadvantage because they'd have to spend resources auditing the tool (and our competitors don't
> have any such tools to audit). We may have to end up shelling out to ps on intel boxes...
>
>
We have the exact same problem with our software, and we too think we're
going to just start popen()ing ps.
Our software can be run as non-root, but it needs to track the status of
its children. It's especially frustrating becuase we only want to call
task_for_pid on processes that have the same UID as our tracking process,
so we really don't want to be root.
Installing a setuid() helper, or even becoming root briefly during the
install to join the procmod group seems like a bad idea- I don't think
anyone wants software that doesn't really need or want root to have to
ask for it; it seems that users should be naturally suspicious of any
software that asks for the administrative passwords, and the more software
that asks for it the less suspcious users become over time.
Now, obviously, task_for_pid() can be a dangerous weapon since you can do
a lot more with it than just get the status of a process. Maybe Apple could
provide a new API that gave read-only accesss to the task, or new APIs to
trace the status of the process (I think FreeBSD has some sysctls that do
most of what we need). Failing that, maybe those of us interested in
this functionality could get together and create a single setuid daemon
so we don't all have to create the same thing over and over again, and
release it with a BSD license or something.
-Erik
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden