Re: hurd/term users.c

[Thomas Bushnell, BSG]

Roland McGrath <roland@gnu.org> writes:

> I don't think that is what "invalid file descriptor" means in anything I
> have read.  That is, things often say e.g. "an invalid file descriptor or a
> file descriptor not opened for reading".  I have always interpreted
> "invalid file descriptor" to mean an integer that does not have a live
> entry in the descriptor table (i.e. unused slots, values higher than the
> table size limit, and negative integers).

Ok, that's fine with me.  But you misunderstand what I don't like. :)

> I take it the behavior you don't like is for a blocking select or poll to
> to actually block waiting for an impossible condition that can never come
> true.  

Certainly that shouldn't happen, but that's not the thing I'm worried
about.  Your approach to how to handle that case is fine with me; I
can see reasons for whether it should block or not, and I trust your
judgment.

The case I'm worried about is a security issue: if I do not have the
port open for reading, I should not be able to get useful data about
when there is data available to be read.  Whether I always block or
always get an error or always get success, no matter to me (though as
per the last paragraph, I'm happy to agree that the right answer is
"always get success").  What's important to me is that I not get
behavior that depends on whether the port has data to be read.

That means that the server routine for select still needs to check
whether the user has the node opened for the particular kind of
access requested, just that instead of my EBADF behavior, it should
instead report success.

Thomas