thanks for your patch - I think this _will_ be useful. Since there are
security implications in giving arbitrary jail root users access to their
own /dev/mem, /dev/kmem, and /dev/io devices, the ability to run `top`
without these items is very useful.
-
John Kozubik - [EMAIL PROTECTED] -
Doesn't top already run in Jail on -CURRENT? Thomas Moestl did this work
a while back, exposing the necessary information to support most of our
userland monitoring tools using sysctl rather than kvm:
last pid: 32655; load averages: 0.05, 0.09, 0.07up 7+14:52:51 09:50:01
2 processes:
The real aim, btw, of moving to sysctl was to allow top (and the other
utilities) without any extra privilege -- be it setuid, setgid kmem, etc.
This had a number of added benefits, including allowing the policy for
process/information visibility to be determined entirely in the kernel
(required
PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND
32652 root 960 1956K 1080K RUN 0:00 0.00% 0.00% top
32650 root 200 1448K 996K pause0:00 0.00% 0.00% tcsh
In general, new features for top go into the cross-platform vendor top
code,
Sorry to bother everyone here but I have a quick question (or I guess
what I hope is a quick question). I have made some modifications to
src/usr.bin/machine.c to allow TOP to run in a jail (I have mostly just
taken out kvm_read's ) and zero'd out alot of information that is not
available to
* Jon Ringuette [EMAIL PROTECTED] [020401 19:20] wrote:
Sorry to bother everyone here but I have a quick question (or I guess
what I hope is a quick question). I have made some modifications to
src/usr.bin/machine.c to allow TOP to run in a jail (I have mostly just
taken out kvm_read's )
That would be pretty cool, why don't you use the gnats:
http://www.freebsd.org/send-pr.html
or just send-pr
to submit your changes?
One idea would be to fail gracefully, when unable to read kvm and
such and keep the -j flag idea you had.
Thats a great idea it didn't even cross my mind to
7 matches
Mail list logo