* Djalal Harouni <tix...@opendz.org> wrote:
> * You can't do it for /proc/*/stat otherwise you will break userspace
> "ps"..., ps must access /proc/1/stat etc... so the proposed solution
> will work without any side effect.
The thing is, returning -EINVAL is not the only way to reject access to
privileged information!
In the /proc/1/stat case a compatibility quirk can solve the problem:
create a special 'dummy' process inode for invalid accesses and give it to
ps, with all fields present but zero.
> And for /proc/*/maps you will perhaps break glibc under certain
> situations... so just hold it for the moment and test it
> later. There have been reports in the past about it.
Same deal: just create a dummy compat-quirk maps inode with constant, zero
information contents to placate old user-space:
00000000-00000000 ---p 00000000 00:00 0
[ Or whatever line is needed to minimally not break old userspace. ]
But don't leak privileged information!
( Maybe add a CONFIG_PROC_FS_COMPAT_QUIRKS Kconfig option, default-y for
now, that new/sane userspace can turn off. )
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
