Re: [screen-devel] [bug #55618] Closing half a million file descriptors on startup

[Jürgen Weigert]

The original closing loop was implemented to make sure child proceses have a few dozen descriptors free when started.

Another aspect is to ban inherited filedescriptors from reading data from the pty. That is a security topic. Not sure how hard it is nowadays to keep a filedescriptor secretly opened to a pty or tty and have it returned to the pool for re-use. On the old hpux multi-user system we had at the campus at that time, it was easy. That should be called a kernel bug, if still possible, I suppose.

If secure, I'd suggest to limit the loop to close the lower 4000 or so.

The exit status of screen is not well defined, I am afraid, There are some invocations that report a count of avalable sessions through the exit status (what a hack), but --version should happily exit(0) .

cheers, JW-

On Fri, Feb 1, 2019 at 4:59 AM Lukas Waymann <address@hidden> wrote:

Follow-up Comment #1, bug #55618 (project screen):

I didn't mention that this causes the screen executable to take much longer to
start.  (I think the command-line arguments don't matter.)

Before:


$ time screen --version
Screen version 4.06.02 (GNU) 23-Oct-17

real    0m0.008s
user    0m0.000s
sys     0m0.009s


After:


$ time screen --version
Screen version 4.06.02 (GNU) 23-Oct-17

real 0m0.170s
user 0m0.057s
sys 0m0.112s


By the way, is the exit status of _screen --version_ intended to be 1?

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?55618>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/