> So what do you do in the case the proc.curproc.rlimit.nofiles.* gets
> pushed below the selected fd?  It's still a valid descriptor.

Thank you, I was going to bring up the same point myself.

> Now, granted, it's a contrived edge case, but...what if?
> Theoretically, we might want to keep stdin, stdout, stderr opened,
> and maybe open a socket or two, but decrease nofiles to 0 to prevent
> a given process from (re)opening another file (call it paranoia).
> What then on select()?

In fact, I have used this ability (having open descriptors above
rlimit.nofiles) in practice.  I took a (now rather old) version of ssh
that did agent access with a file descriptor left open and its number
stuck in an environment variable.  But I wanted to sneak this past a
shell-like program that closed all open files except the ones it had
open for its own purposes.  So I hacked on the sshd to dup2 the
descriptor to a high number and then set rlimit.nofiles just below
that.  The "shell" closed everything up to getdtablesize(), which of
course left the agent descriptor open, where later, ssh runs could find
it and use it normally.

Now, I don't know whether it ever actually got passed to select(), but
it certainly plausibly could have been.  (Also note that whether you
think this was a good technique (indeed, whether I today think it was)
is more or less irrelevant to my point.  If I've done it in one
context, various other people probably have too in other contexts....

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B