Re: psi commit d5fd8820591c: Updated ProcessAttributeTests for Darwin behaviour where Process.command and Process.argc are not available for pid 0 even if superuser.

[Floris Bruynooghe]

On Wed, Nov 11, 2009 at 11:08:09AM +0000, commits...@bitbucket.org wrote:
> Updated ProcessAttributeTests for Darwin behaviour where Process.command and Process.argc are not available for pid 0 even if superuser.

Just out of interest, what is pid 0 on Darwin? Afaik it's the swapper
process on traditional UNIX but normally not visible in the process
table.

Floris

[Chris Miles]

The Process.name of pid 0 is 'kernel_task'. ps on OS X hides it, but
Activity Monitor (OS X GUI app) shows it in the process list. It
looks like it represents the kernel activity. Activity Monitor shows
CPU%, Thread count and memory usage for it, which I'd assume are stats
about the kernel itself.

Cheers,
Chris

[Floris Bruynooghe]

Fair enough, but I think you should fill in .argc and .command anyway.
We promise that here:
http://bitbucket.org/chrismiles/psi/wiki/ProcArgsExe

It's not that much of a leap I think, argc=0 and .command == .name In
fact if you leave .command as an empty string and set the status to OK
then the python code will just look up .name and use that.

I hope you agree

Floris

--
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

[Chris Miles]

That makes sense. I don't have all the best practices & user promises
in my head due to infrequent involvement, so feel free to continue
pointing out where I've messed up.

I've changed the Darwin code to ensure that .command & .argc contains
valid values, as you suggest.

One question, what are we doing with these attributes in the case
where the user doesn't have privilege to access their true values? My
current example is with Darwin's pid=1 process:

$ sudo ipython
In [1]: import psi.process

In [2]: p = psi.process.Process(1)

In [3]: p.name
Out[3]: 'launchd'

In [4]: p.command
Out[4]: '/sbin/launchd'

In [5]: p.argc
Out[5]: 1L

$ ipython
In [1]: import psi.process

In [2]: p = psi.process.Process(1)

In [3]: p.name
Out[3]: 'launchd'

In [4]: p.command
Out[4]: 'launchd'

In [5]: p.argc
Out[5]: 0L

In the second (non privileged case) .command copies .name and .argc is
set to 0. Does argc=0 make sense, or should it default to argc=1
(unless command is an empty string, perhaps)?

Cheers,
Chris

[Floris Bruynooghe]

On Thu, Nov 12, 2009 at 01:19:41PM +1100, Chris Miles wrote:
> One question, what are we doing with these attributes in the case
> where the user doesn't have privilege to access their true values? My
> current example is with Darwin's pid=1 process:

Hum, haven't seen this before. On systems with a /proc you can always
get p.command and p.argc even if you're not root. I think we don't
have to worry about p.command, that's a "best effort" anyway, so
having that different between root and non-root is ok (if you want it
accurate you need to use p.args). But getting p.argc correct would be
good.

Is this only a special case for pid=1 or is this true for every
process you don't have privileges for on Darwin? If it's the former
you could special case pid=1 I guess (or do what you suggested: argc=0
if command is empty, otherwise argc=1), if it's the later we may have
to rethink promising p.argc to be always available.

Regards

[Chris Miles]

On 12/11/2009, at 9:21 PM, Floris Bruynooghe wrote:

>
> On Thu, Nov 12, 2009 at 01:19:41PM +1100, Chris Miles wrote:
>> One question, what are we doing with these attributes in the case
>> where the user doesn't have privilege to access their true values? My
>> current example is with Darwin's pid=1 process:
>
> Hum, haven't seen this before. On systems with a /proc you can always
> get p.command and p.argc even if you're not root. I think we don't
> have to worry about p.command, that's a "best effort" anyway, so
> having that different between root and non-root is ok (if you want it
> accurate you need to use p.args). But getting p.argc correct would be
> good.
>
> Is this only a special case for pid=1 or is this true for every
> process you don't have privileges for on Darwin? If it's the former
> you could special case pid=1 I guess (or do what you suggested: argc=0
> if command is empty, otherwise argc=1), if it's the later we may have
> to rethink promising p.argc to be always available.

I tested with another root owned process and got the same behaviour. Looks like we can't promise argc on Darwin when the user doesn't have the correct privileges.

I don't know if there are any other ways to get at argc/etc without privileges. However, both /bin/ps and /usr/bin/top have the setuid bit set (for root) so I suspect not.

Cheers,
Chris

[Floris Bruynooghe]

[Sorry I seemed to have missed this mail when you first sent it]

Ok, I don't think there's any major disadvantages to drop the promise
of p.argc being always available. I think it's only there because all
the platforms where always able to provide it. If no one disagrees
with that could you update the Darwin code to set it to PSI_STATUS_NA?

And would Darwin be ready for a release after that change?

Thanks

[Chris Miles]

On 19/11/2009, at 8:43 PM, Floris Bruynooghe wrote:

>> I tested with another root owned process and got the same behaviour.
>> Looks like we can't promise argc on Darwin when the user doesn't
>> have the correct privileges.
>>
>> I don't know if there are any other ways to get at argc/etc without
>> privileges. However, both /bin/ps and /usr/bin/top have the setuid
>> bit set (for root) so I suspect not.
>
> Ok, I don't think there's any major disadvantages to drop the promise
> of p.argc being always available. I think it's only there because all
> the platforms where always able to provide it. If no one disagrees
> with that could you update the Darwin code to set it to PSI_STATUS_NA?

Shouldn't we leave it as PSI_STATUS_PRIVS? A value for argc is available if the user has the correct privileges.

>
> And would Darwin be ready for a release after that change?

Two other things remain for Darwin:

* Fix boottime/uptime - these are broken, on Snow Leopard at least. I don't have any Macs running pre-Snow Leopard to confirm, but I'd like to get these working on the current OS release at least.

* mount attributes.

The first one definitely needs to be fixed and I'll work on that next. The second one we could probably release without support for it if we need to then add it as quickly as we can. So long as we document the fact that it doesn't work on OS X.

Cheers,
Chris

[Chris Miles]

On 20/11/2009, at 6:54 PM, Chris Miles wrote:

>> And would Darwin be ready for a release after that change?
>
> Two other things remain for Darwin:
>
> * Fix boottime/uptime - these are broken, on Snow Leopard at least. I don't have any Macs running pre-Snow Leopard to confirm, but I'd like to get these working on the current OS release at least.
>
> * mount attributes.
>
> The first one definitely needs to be fixed and I'll work on that next. The second one we could probably release without support for it if we need to then add it as quickly as we can. So long as we document the fact that it doesn't work on OS X.

And I've now updated these two things, so all tests are passing on Darwin for me (on Snow Leopard).

Only remaining question is the error to return for argc when not privileged. PSI_STATUS_PRIVS or PSI_STATUS_NA

Cheers
Chris

[Floris Bruynooghe]

On Fri, Nov 20, 2009 at 06:54:21PM +1100, Chris Miles wrote:
>
> On 19/11/2009, at 8:43 PM, Floris Bruynooghe wrote:
>
> >> I tested with another root owned process and got the same behaviour.
> >> Looks like we can't promise argc on Darwin when the user doesn't
> >> have the correct privileges.
> >>
> >> I don't know if there are any other ways to get at argc/etc without
> >> privileges. However, both /bin/ps and /usr/bin/top have the setuid
> >> bit set (for root) so I suspect not.
> >
> > Ok, I don't think there's any major disadvantages to drop the promise
> > of p.argc being always available. I think it's only there because all
> > the platforms where always able to provide it. If no one disagrees
> > with that could you update the Darwin code to set it to PSI_STATUS_NA?
>
> Shouldn't we leave it as PSI_STATUS_PRIVS? A value for argc is
> available if the user has the correct privileges.

Oh, yes of course.

> > And would Darwin be ready for a release after that change?
>
> Two other things remain for Darwin:
>
> * Fix boottime/uptime - these are broken, on Snow Leopard at
> least. I don't have any Macs running pre-Snow Leopard to confirm,
> but I'd like to get these working on the current OS release at
> least.
> * mount attributes.
>
> The first one definitely needs to be fixed and I'll work on that
> next. The second one we could probably release without support for
> it if we need to then add it as quickly as we can. So long as we
> document the fact that it doesn't work on OS X.

Ok, I'm happy waiting if you're working on them and want them
completed.

[Floris Bruynooghe]

On Fri, Nov 20, 2009 at 08:41:57PM +1100, Chris Miles wrote:

> Only remaining question is the error to return for argc when not
> privileged. PSI_STATUS_PRIVS or PSI_STATUS_NA

PRIVS obviously, I was just confused before. Sorry about that.

Thanks for all the work!

[Chris Miles]

On 20/11/2009, at 10:24 PM, Floris Bruynooghe wrote:

> On Fri, Nov 20, 2009 at 08:41:57PM +1100, Chris Miles wrote:
>
>> Only remaining question is the error to return for argc when not
>> privileged. PSI_STATUS_PRIVS or PSI_STATUS_NA
>
> PRIVS obviously, I was just confused before. Sorry about that.

No problem, just thought I'd check.

All tests pass on OS X (Snow Leopard) now. If anyone watching is running OS X (especially pre-Snow Leopard) it would be very handy if you could run the tests.

Otherwise, I think we're ready for a release. I'll leave that in your hands Floris.

Cheers,
Chris