Hi, I think it is a very deep conceptual issue and a very deep difference in thinking about availability of features... "As close and restricted as possible" vs "allow as much as possible". Lets see two cases: If you are building a nuclear power plant, you want everything specified and doing exactly the thing you want it to do, but nothing more. You want everything documented, proven to be only there if needed, and doing just the things it needs to do. If you are building an experimental herb and flower garden, you want random influences and as much potential as possible. A secure Linux server sadly should act more like a nuclear power plant as break ins will cause fallout than a herb garden. Ciao, Marcus On Mon, Dec 05, 2011 at 08:40:41AM -0800, Greg KH wrote:
Again, what is exploitable today, it will be fixed.
Seeing that even interrupt numbers / timings are used to guess passwords nearly any information can be a side channel of sensitive information.
I understand your feeling that we are exposing "too much", but without a specific example of what is wrong here, I'm not going to want to see anything changed.
So: Does "perf" need to run as user, or can it just be run as "root"?
It can run as user, and it provides very good statistics as a user, you should try it sometime :)
Could we restrict the mount permissions of debugfs to only be root readable?
No, a patch to do so was rejected upstream for the reasons I cite above.
thanks,
greg k-h
-- Working, but not speaking, for the following german company: SUSE LINUX Products GmbH, HRB 16746 (AG Nuernberg) Geschaeftsfuehrer: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org