[3298] in Release_7.7_team

home help back first fref pref prev next nref lref last post

Re: Athena Disconnected Operation White Paper Draft 2.

daemon@ATHENA.MIT.EDU (Derek Atkins)
Fri May 24 19:44:09 2002

To: tb@becket.net (Thomas Bushnell, BSG)
Cc: Bill Cattey <wdc@MIT.EDU>, source-developers@MIT.EDU, release-team@MIT.EDU
From: Derek Atkins <warlord@MIT.EDU>
Date: 24 May 2002 19:44:02 -0400
In-Reply-To: <87znypnn20.fsf@becket.becket.net>
Message-ID: <sjm3cwhjem5.fsf@kikki.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Well, I don't know about you, but from a security standpoint I would
much rather have the "normal system rendezvous point for
connection/disconnection" send an event to a process running in the
user's environment, rather than trying to subvert all the particular
security procedures in place.

Note that it may NOT be possible to join an arbitrary PAG, especially
once PAGs are supported natively in the kernel (which appears to be
happening in Linux 2.5).  So, no, root cannot "certainly get into the
user's pag", at least not without loading a special kernel module that
adds a hook to violate the PAG security model.

I agree that starting from the existing scripts is the way to go.  I
thought I made that clear in my proposal.  However I also feel that
there is enough work to be done for the user that having a way to
"signal the user" would be a Good Thing.  What is described is my
proposal for how to signal a user by providing yet another rendezvous
point and a set of "default things to do on behalf of the user".

-derek

tb@becket.net (Thomas Bushnell, BSG) writes:

> I don't think an endless discussion is helpful here, but let me just
> clarify...
> 
> I'm not saying that there is no work to be done... perhaps at login
> time there is a certain amount of info the user should squirrel away.
> Indeed, that seems totally necessary whatever happens.  So granted
> that at login time the user (or a script run at login time on his
> behalf) needs to scribble down things like the location of the ticket
> file and such.
> 
> Root can certainly get into the user's pag.  Even if the kernel
> doesn't provide a call for it, root can easily subvert pag...in which
> case, root should just have a straightforward way to do the right
> thing directly.  That's easy to fix.
> 
> My point is that this can all be initiated by a script running as root
> from the normal system rendezvous point for connection/disconnection
> actions.  
> 
> Thomas

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available

home help back first fref pref prev next nref lref last post