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

On Mon, Nov 18, 2002 at 03:26:15PM +0100, Marcus Brinkmann wrote:
> * This is absed on Neal's patch for record file locking.  I changed flock_t
> to flock64_t, as we are all 64 bit now.  Also I added a lifetimer port,
> which can be used by the server to request deadname notifications on.  The
> idea is that the client creates one dummy port for all record locks, and if
> the task dies, the dummy port is destroyed and the server can clean up all
> the record locks that should now go away according to POSIX.

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.

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.

This is by far not a complete list, I am sure.  Below some more cases I
studied, but I have not went through all interfaces.


These cases could be problematic, but are not for special reasons:

* The crash server gets a lot of prt refs, but I think it works anyway
  because it also gets the task port and implicitely checks if the task port
  is valid.

* The file/dir notice changes RPCs are quite safe, as they test the port by
  sending an initial change notification to the port and don't accept the port
  if that fails - and it will fail for all the system ports we care about.

* file_reparent is safe as the port is deallocated when the reparented port
  has no users anymore.

The following cases I am not sure about:

* fsys_startup: Is the control port deallocated when realnode has no more
  users?

* fsys_getroot: When is dotdot deallocated?

* fsys_forward: The test here is if the requestor accepts fsys_startup.  I
  am not sure if you could setup a cycliv reference leak using this.

etc etc etc.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    [email protected]
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
[email protected]
http://www.marcus-brinkmann.de/