Re: port reference leaks (was: Re: new interfaces io_close, io_reidentify, file_record_lock

[Marcus Brinkmann]

On Tue, Dec 03, 2002 at 08:28:17PM -0800, Thomas Bushnell, BSG wrote:
> Marcus Brinkmann <address@hidden> writes:
> > This doesn't work.  Well, it would work, but it is dangerous.
> > 
> > Imagine that a task provides a a send right for a port that is not in the
> > task, but in some other task.  For example another system filesystem, or an
> > auth port.  Then the task can die, effectively leaking both resources, the
> > resources of the port it provided, and the file lock.
> 
> Yeah.  
> 
> > In general, we never must accept user provided port references in the server
> > "for a long time".  We already violate that!
> > 
> > * The auth server keeps a ref for the rendezvous port.  If that port is
> >   not by the user, the user can exit and the reference is effectively 
> > leaked.
> > 
> > * You create a pipe, then you call io_select_request on that pipe, with the
> >   reply port being the write end of the pipe itself.  Then you exit.
> 
> So we need a way other than port death notifications to handle this?
> I don't think so.  I'm not certain there is a problem here.

Well, it depends what you define as being a problem.  Personally I think
that resources should always be accountable, ie, you can always at least
principially find out who occupies a resource, and you should be able to
free the resource by killing those tasks which occupy it.  Well, at least
for all live resources which are transient (ie, I don't mean files, but
"open files", locks, memory, etc).

Or, in other words, if you go into single user mode from multi user mode,
except for purposefully static resources like files in the filesystem, and
maybe things like shared memory, all resources should be freed, and the
system should basically be in the state as it was in when you booted the
system.  A user should not be able to consume resources and hide them away
so that they can not be freed anymore.

Now, imagine the pipe case above.  A user can create a pipe.  When the pipe
handles are released, the pipe is destroyed.  So far, so good.  Now, the
above scenario describes a way for a user to hide the pipe handles in the
pipe server itself.  If the task then releases its own references for them,
the pipe is not accounable anymore.  Although it exists, there is no way to
get to it anymore.  The resources associated with the pipe will never be
released.

If this is possible, you can never, ever make the system robust.  You can
never rely on quota mechanisms to limit resource consumption.  Compare this
with EROS, where the system is designed to have the user donate even the CPU
time the server needs to perform the desired operation.  I just think that
the system needs to be revised to be much more paranoid.  I think that could
be done when porting the Hurd to L4.  Only some small fundamental changes 
should be
necessary.

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/