"ps -e" without procfs(5)

[Mikolaj Golub]

On Tue, 25 Oct 2011 11:24:51 +0300 Kostik Belousov wrote:

 KB> On Tue, Oct 25, 2011 at 12:13:10AM +0300, Mikolaj Golub wrote:
 >> 
 >> On Sun, 16 Oct 2011 20:10:05 +0300 Kostik Belousov wrote:
 >> 
 >>  KB> In my opinion, the way to implement the feature is to (re)use
 >>  KB> linprocfs_doargv() and provide another kern.proc sysctl to retrieve the
 >>  KB> argv and env vectors. Then, ps(1) and procstat(1) can use it, as well as
 >>  KB> procfs and linprocfs inside the kernel.
 >> 
 >> Thanks! I am testing a patch (without auxv vector so far) and have some
 >> questions.
 >> 
 >> Original ps -e returns environment only for user owned processes (the access is
 >> restricted by the permissions of /proc/pid/mem file). My kern.proc.env sysctl
 >> does not have such a restriction. I suppose I should add it? What function I
 >> could use for this?
 >> 
 >> BTW, linprocfs allows to read other user's environment.
 KB> linprocfs uses p_cansee() to check the permissions. There are sysctls
 KB> security.bsd.see_other_{ug}ids that control the behaviour.

 KB> I believe that the new sysctl shall use the same check.

This looks reasonable for me. But I just wanted to be sure that this would be
ok for other people, as my patch changes the system behavior: currently with
security.bsd.see_other_{ug}ids and procfs (not linprocfs) mounted a user can
see other users args but not env; after the change a user will see both args
and env (until security.bsd.see_other_{ug}ids is off).

 >> 
 >>  KB> While you are at the code, it would be useful to also export the auxv vector,
 >>  KB> which is immediately before env.
 >> 
 >> It looks I can find the location of auxv but what about the size? Or do you
 >> propose to extend struct ps_strings to store location and size of auxv? I
 >> could do this way...

 KB> No, extending ps_strings is not needed and it is too radical change.
 KB> The auxv vector must end by the AT_NULL aux entry. You can also artificially
 KB> limit the amount of read aux vectors to, say, 256, which is much more then
 KB> it is currently defined.

Thanks.

-- 
Mikolaj Golub