Some further thoughts before I doze off: > > allowed to. This should be controlled by sysctls like > (placement based > > on nfs and ffs sysctl placement precedent): > > Or even a mount option to procfs :)
After some thought, I think the mount option idea is best. I hadn't thought of that before. One might want to apply different procfs security policies to different mounts of procfs, especially in a jail() situation. Good call. > > I think the idea (of a procfs ps) was shot down on the > lists some time > > ago because ps needs to retain the ability to look at > the process list > > in a kernel coredump. IMHO that's a lot of messy kvm > groveling and > > associated kernel-to-userland sync dependencies, just to > cater to the > > (generous figure) 0.5% of the people out there who have > 1) a crashing > > FreeBSD box and 2) the expertise and the will to debug > the crash dump. > > I think that issue needs to be revisited somehow. > > Well.. I do use crash dumps, but rarely use ps on them.. > Even so you could have > 2 implementations of ps, or a ps which allows you to > compile in a different > 'back end'. That way you can use either easily. I think that the best idea here is a single ps implementation with both backends available. Normally it would use the simple, secure and possibly privacy-enhancing procfs method, but using the -M or -N options to specify a dump or kernel file (or the live /dev/kmem and /kernel, if one were so inclined) would automagically switch ps over to the kvm grovel method. This would make the change transparent to both users and developers. SGID can still be removed - a developer/debugger will already be root or have had to chown the dump/kernel files to do any debugging. It would be mild bloat, but disk is cheap, and a disk space to debugging ease tradeoff has already been made (to the tune of several megs!) by the decision to build debug kernels by default. I agree with that. One could also #ifdef the kvm version. Jason Young accessUS Chief Network Engineer To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
