Subject: Re: Restricting kern.proc* access
To: None <email@example.com>
From: Gregory McGarry <firstname.lastname@example.org>
Date: 10/19/2001 08:53:08
> The patches introduce two new sysctls, kern.restrict_proc and
> kern.restrict_ proc_gid.
> When kern.restrict_proc is set to 1, (it defaults to 0) only root
> and those users in the group specified numerically by
> kern.restrict_proc_gid may view the details of processes they do
> not own. Normal users may only see their own processes.
> I believe this patch is useful because it gives users privacy
> from each other whilst at the same time not limiting the genuine
> need for some users (say, system administration staff) to be able
> to see everything that is going on without always becoming the
> superuser. One example where this would be useful is on a shell
> server. (depending on it's policy)
I recall seeing in Irix or Solaris a facility on departmental
supercomputers where the system resources could be divided
based on "classes". If you belong to a specific "class" you
can only use the resources (eg memory, cpus) allowed by your
"class" and cannot see/interact with users not in your
"class". Good idea if you have commercial users sharing
your system with each other.
I use the term "class" since it is distinct from login
classes currently used in NetBSD.
I realise that NetBSD doesn't specifically target these
installations, but I always thought it would be useful
to have. It could be implemented incrementally, starting
with userland and moving to scheduler modifications.
I mention it now because kern.restrict_proc seems like
a specific example of this concept.
-- Gregory McGarry <email@example.com>