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/

Reply via email to