🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: net.bugs.v7
Article #100

dup/dup2 vs close-on-exec

#100
From: utzoohenry
Date: Wed, 24 Nov 1982 20:39
19 lines
1410 bytes
Dup() and dup2() are unaware of the u_pofile array, which contains
(at the moment) the close-on-exec flags for the file descriptors.
Dup() always returns a stays-open-on-exec descriptor, since ufalloc()
zeros out the u_pofile slot for the descriptor it returns.  Now comes
the fun part!  Dup2() does not use ufalloc(), so the descriptor it
gives back simply inherits the previous value of the u_pofile entry.
This is lots of fun, because close() does not zero out u_pofile!
Nor does exec()!  Even the code for exec() that does handle u_pofile --
the close-on-exec handling -- gets it wrong:  it clears only the
close-on-exec bit, not the whole word.

All of this would be much more serious if there were more useful bits
in u_pofile.  As it is, it's not surprising that nobody noticed.

The fix should be fairly straightforward, although I have *not*
tested it.  The code in sys3.c that implements dup() and dup2()
should carry the u_pofile contents along with the descriptor when
duplicating it.  I think I would also be inclined to zero out the
u_pofile entry when the descriptor is closed, just in case.
Technical Details
Message-ID: <bnews.utzoo.2639>
Path: arc1-ca.pugleaf.net!unknown!not-for-mail

Show Full Headers
Complete Article Headers
From: utzoo!henry
Newsgroups: net.bugs.v7
Title: dup/dup2 vs close-on-exec 
Article-I.D.: utzoo.2639
Posted: Wed Nov 24 20:39:52 1982
Received: Wed Nov 24 20:39:52 1982
Subject: dup/dup2 vs close-on-exec
Date: Wed, 24 Nov 1982 20:39:52 +0000
Message-ID: <bnews.utzoo.2639>