Description of problem: Then I cat /proc/iomem under non-root user I get very weird results. /proc/iomem looks kinda like it supposed to look like except every address range are 00000000-00000000. Under root it behaves as expected. [test@lenovo-rd230-02 ~]$ head /proc/iomem 00000000-00000000 : reserved 00000000-00000000 : System RAM 00000000-00000000 : reserved 00000000-00000000 : PCI Bus 0000:00 00000000-00000000 : Video ROM 00000000-00000000 : Adapter ROM 00000000-00000000 : Adapter ROM 00000000-00000000 : Adapter ROM 00000000-00000000 : PCI Bus 0000:00 00000000-00000000 : reserved Under root: [root@lenovo-rd230-02 ~]# head /proc/iomem 00000000-00000fff : reserved 00001000-0009a3ff : System RAM 0009a400-0009ffff : reserved 000a0000-000bffff : PCI Bus 0000:00 000c0000-000c7fff : Video ROM 000c8000-000c8fff : Adapter ROM 000c9000-000c9fff : Adapter ROM 000ca000-000cafff : Adapter ROM 000d0000-000dffff : PCI Bus 0000:00 000e0000-000fffff : reserved Version-Release number of selected component (if applicable): [test@lenovo-rd230-02 ~]$ uname -r 4.6.7-200.fc23.x86_64 How reproducible: Every time. Steps to Reproduce: 1. su - test 2. cat /proc/iomem Expected results: It should print real addresses or return ioerror when reading /proc/iomem. But I don't think returning wrong addresses are sane behaviour. Additional info: on RHEL6 and RHEL7 cat /proc/iomem under unprivileged user returns same as under root.
This was intentionally changed with commit 51d7b120418e99d6b3bf8df9eb3cc31e8171dee4 Author: Linus Torvalds <torvalds> Date: Thu Apr 14 12:05:37 2016 -0700 /proc/iomem: only expose physical resource addresses to privileged users In commit c4004b02f8e5b ("x86: remove the kernel code/data/bss resources from /proc/iomem") I was hoping to remove the phyiscal kernel address data from /proc/iomem entirely, but that had to be reverted because some system programs actually use it. This limits all the detailed resource information to properly credentialed users instead. Signed-off-by: Linus Torvalds <torvalds> which was in the 4.6 kernel release.
Thanks Josh, I wasn't aware about this. However it still feels as wrong behaviour to me. I guess it would be more sane if it would behave more like let say /proc/$some_id/environ . I mean If privileged user tried to read that it would return real values and if unprivileged user wants to read that it would end up with Permission Denied or ioerror. But I guess correct place to brag about this is kernel mailing list. btw: thanks again Josh for super fast responce.
(In reply to Andrej Manduch from comment #2) > Thanks Josh, > > I wasn't aware about this. However it still feels as wrong behaviour to me. > I guess it would be more sane if it would behave more like let say > /proc/$some_id/environ . I mean If privileged user tried to read that it > would return real values and if unprivileged user wants to read that it > would end up with Permission Denied or ioerror. > > But I guess correct place to brag about this is kernel mailing list. Right. > btw: thanks again Josh for super fast responce. No problem.