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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
