[DGD] ownership

Noah Gibbs noah_gibbs at yahoo.com
Sat Nov 3 07:41:54 CET 2007


  I'm looking through mud/kernel/lib/auto.c, in the destruct_object() function,
and it looks like only Kernel objects can destruct other Kernel objects unless
it's a library that's being destructed (and in this case, it isn't).

  You're probably just going to have to pass an appropriate "disconnect" error
code up the chain if you want the kernel lib to destroy the connection for you.

  Or, as you say, you could patch the kernel lib.  That's messy, though.

--- "chris ." <psych_mayo at hotmail.com> wrote:

> 
> Any object under the /System/ path should be able to destroy other objects, 
> unless they were created in the kernel.  Is that right?
> I am trying to destruct inbound connections based on their ip.  I thought
> that
> the best place to do this would be the query_banner function in telnetd.
> Although telnetd is in the /System/ path, it cannot destruct the connection
> object passed into query_banner.  I am looking for a means to do this without
> 
> writing to the  kernel library, for obvious reasons.  Should i stick with the
> patch 
> to kernel lib, or is there a means to give permission to destruct.  
> A thought i have would be to have a user-defined kernel level daemon.  I do
> not like the direction of this though. 
> My key assumption is that there is a kernel level of ownership, above system
> .
> 
> 
> > Date: Fri, 2 Nov 2007 21:17:41 -0700
> > From: noah_gibbs at yahoo.com
> > Subject: Re: [DGD] ownership
> > To: dgd at dworkin.nl
> > 
> >   In general, the same owner needs to create and destroy a given object. 
> The
> > exception is System, which can destroy somebody else's object (if I
> remember
> > right).
> > 
> >   But for bookkeeping purposes, your best bet is to make sure that the same
> > object that creates an object destroys it.  It's clean, it's simple, it
> works. 
> > If that's not easily possible, I think any object under the same /usr/blah
> > directory (that is, the same 'blah' :-) will work.
> > 
> > --- "chris ." <psych_mayo at hotmail.com> wrote:
> > 
> > > 
> > > Just a little confused on some aspects of the kernel libraries ownership
> and
> > > security scheme.
> > > To cut to the chase, I want to destruct a cloned kernel object from a
> daemon
> > > in usr/System/.
> > > I am trying to do this without altering the kernel library.  I already
> have a
> > > solution that does, 
> > > but i would like to leave the kernel library untouched.  Trying to
> destruct
> > > from my daemon
> > > gives me an ownership error.  Calling a function in the object that would
> > > result in it being 
> > > destructed does nothing (i am trying to destruct the  connection object
> from
> > > inside telnetd, 
> > > in the query_banner function.  Destructs connections of sitebanned ips).
> > > There must be an approach to handle this sort of thing, and i am not in
> the
> > > know.
> > > Help and insight would be appreciated.  Thanks
> > > 
> > > _________________________________________________________________
> > > Climb to the top of the charts!  Play Star Shuffle:  the word scramble
> > > challenge with star power.
> > >
> >
>
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_oct___________________________________________
> > > https://mail.dworkin.nl/mailman/listinfo/dgd
> > > 
> > 
> > 
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around 
> > http://mail.yahoo.com 
> > ___________________________________________
> > https://mail.dworkin.nl/mailman/listinfo/dgd
> 
> _________________________________________________________________
> Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare!
>
http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
> 




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



More information about the DGD mailing list