DragonFly bugs List (threaded) for 2004-04
Re: troubles with caps
:I've been playing with it quite heavily in the past few days and I like
:it a lot. I have two questions about it though, if you don't mind:
:Do you have any plans to introduce a timeout to (say) caps_sys_wait, so
:that if a message doesn't come in in a certain time frame, it returns
:with errno == ETIMEOUT or similar?
I've been thinking about tying it into the file descriptor subsystem
but there are issues related to programs fork()ing and closing all
descriptors that makes it difficult for a libc implementation to
properly deal with the fork.
But, yes, I think we do need some sort of timeout feature.
:And, when the process which is holding a connection dies, does that
:connection die too? From the looks of the client example (which forks)
:I'm guessing no, the connection sticks around and can be shared by
:several processes. But is there a guarantee of that? Say I'd like to
The connection is actually NOT shareable between processes that
fork(). What happens when you fork is that a dummy placeholder
connection is created in the child so if the child tries to access
the CAPS descriptor it gets a specific error that it can check for and
know when to reconnect.
The problem with closing out the CAPS descriptor is that if the child
process then makes various other CAPS connections before attempting
to use a connection it think is still good from before the fork, the
new connections might reuse the ID that the original connection had.
:be able to receive a message with one process and pass the connection id
:to another process that replies to it. In the meantime the first
:process might exit... should I instead be re-establishing a new
:connection in each process?
You can't pass connection id's. If we implement a file descriptor based
approach then it would be possible to pass connection id's but the
hanging point there are as described above... programs which close all
I'm not sure how advantageous it would be to pass CAPS connections between
processes, since a process can easily reconnect to the CAPS service and/or
the original process can create a new service that the new process
connects to. I think it might be better to enforce the current API
which allows no connection inheritance or passing.
From a security standpoint we might want to manage capabilities through
the CAPS system (in the future), and in that case we definitely do not
want to allow connection inheritance. At the moment that's just a
pipe dream. I have to add a way for the server to recognize a particular
client's connection before capability management can be done properly.