On Sun, 2005-04-10 at 17:38 +0200, Rene Scharfe wrote: > Albert, allowing access based on tty sounds nice, but it _is_ expansive. > More importantly, perhaps, it would "virtualize" /proc: every user would > see different permissions for certain files in there. That's too comlex > for my taste.
If you really can't allow access based on tty, then at least allow access if any UID value matches any UID value. Without this, a user can not always see a setuid program they are running. > First, configuring via kernel parameters is sufficient. It simplifies > implementation a lot because we know the settings cannot change. And we > don't need the added flexibility of sysctls anyway -- I assume these > parameters are set at installation time and never touched again. This means mucking with boot parameters, which can be a pain. The various boot loaders do not all use the same config file. > Then I suppose we don't need to be able to fine-tune the permissions for > each file in /proc/<pid>/. All that we need is a distinction between > "normal" users (which are to be restricted) and admins (which need to > see everything). The /proc/*/maps file sure is different from the /proc/*/status file. The same for all the others, really. > This patch introduces two kernel parameters: proc.privacy and proc.gid. > The group ID attribute of all files below /proc/<pid> is set to > proc.gid, but only if you activate the feature by setting proc.privacy > to a non-zero value. This is very bad. Please do not change the GID as seen by the stat() call. This value is used. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
