I think teaching the kernel is the more progressive way to do it, and if
there's framework for the kernel to check things based on login classes,
this could be extended in the future, to allow more selective permission
for a number of things.

/joseph

--
Joseph Mallett           Security Specialist
jmallett@newgold.net         www.newgold.net

irc.newgold.net/#xMach       xMach Core Team
jmallett@xMach.org             www.xMach.org

xMach Research Group            www.xmrg.com

<josephm> Crystal Pepsi: sure it caused cancer,
          but it was leet.

On Tue, 17 Apr 2001, matthew green wrote:

> 
>    On Fri, Apr 13, 2001 at 12:43:38PM -0400, Joseph Mallett wrote:
>    > It could be part of login classes, and limit user per user who can see
>    > others' processes. This would be the "best" way, but not the easiest one.
>    
>    Whilst that's not the easiest solution, I agree that it is probably
>    the "best" way.
>    
>    Too much magic already depends upon the test of uid==0; using login
>    classes makes sense.
>    
>    Actually reminds me of a university system I had an account on years
>    ago; only the sysops (in a certain group) could run the full ps;
>    everyone else was restricted...
> 
> 
> i'm curious as to implementation thoughts for this -- does the kernel
> get to learn about classes or do we get a ps daemon or do we go back
> to a set-id ps?  all sounds rather ugly to me.
> 
> 
> .mrg.
>