Date: Tue, 25 Oct 2011 11:24:51 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Mikolaj Golub <trociny@freebsd.org> Cc: freebsd-hackers@freebsd.org, Robert Watson <rwatson@freebsd.org> Subject: Re: "ps -e" without procfs(5) Message-ID: <20111025082451.GO50300@deviant.kiev.zoral.com.ua> In-Reply-To: <86aa8qozyx.fsf@kopusha.home.net> References: <86y5wkeuw9.fsf@kopusha.home.net> <20111016171005.GB50300@deviant.kiev.zoral.com.ua> <86aa8qozyx.fsf@kopusha.home.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
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.
linprocfs uses p_cansee() to check the permissions. There are sysctls
security.bsd.see_other_{ug}ids that control the behaviour.
I believe that the new sysctl shall use the same check.
>
> 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...
No, extending ps_strings is not needed and it is too radical change.
The auxv vector must end by the AT_NULL aux entry. You can also artificially
limit the amount of read aux vectors to, say, 256, which is much more then
it is currently defined.
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iEYEARECAAYFAk6mclMACgkQC3+MBN1Mb4jRxgCgwjXXtNzpDxyeSGSYnSdW+9gD
fB8AoK3noTKoVjj+w6FdHsciqmQwsqs3
=PDhD
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111025082451.GO50300>
