[Python-bugs-list] [ python-Bugs-803610 ] os.close(3) raises OSError: [Errno 9] Bad file descriptor

[SourceForge.net]

Bugs item #803610, was opened at 2003-09-10 06:18
Message generated for change (Comment added) made by syrah
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=803610&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Syrah (syrah)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.close(3) raises OSError: [Errno 9] Bad file descriptor

Initial Comment:
os.close(3) raises OSError: Bad file descriptor on

FreeBSD 5.1, with both Python 2.2.2(_2) and 2.3(_1). 

Python 2.3 on Gentoo Linux 1.4 is not affected.



Interestingly, if you call os.fstat(3) first, a

subsequent call to os.close(3) succeeds.



And yes, you do need to set up fd #3.



Here is a demonstration (on FreeBSD):



[syrah at ripple filter]$ cat test.py

import os

os.close (3)



[syrah at ripple filter]$ python test.py 3> file

Traceback (most recent call last):

  File "test.py", line 2, in ?

    os.close (3)

OSError: [Errno 9] Bad file descriptor



[syrah at ripple filter]$ cat test2.py

import os

os.fstat (3)

os.close (3)



[syrah at ripple filter]$ python test2.py 3> file



[syrah at ripple filter]$   (success!)



----------------------------------------------------------------------

>Comment By: Syrah (syrah)
Date: 2003-09-10 17:33

Message:
Logged In: YES 
user_id=827529

I'm writing a mail filter for the courier mail server.



Before courier forks the filter, courier sets up fd 3 to

communicate with the filter.  When the filter has finished

initialization and is ready for work, the filter is supposed

to close fd 3.  Courier detects the closure of fd 3 and

knows that the filter is ready to work.



In general, before a call to fork/exec, the parent process

can set up any number of file descriptors for the child to

inherit.  If you are writing such a child in C, it is easy

to use these "extra" file descriptors.  It would nice to be

able to write in Python instead.



Saying that "3 *is* a bad file descriptor" assumes that

every program will be run from the command line, and the the

command line will only set up fd's 0, 1 and 2.  This is not

the case.  In fact it is very easy to set up other file

descriptors on the command line using bash.  See my example

above.



Another example of using more than 0, 1 and 2.  The openssl

program can use arbitrary file descriptors (referenced by

number on the command line) to recieve passwords.  This

allows you to cleanly pass in multiple passwords in a

reasonably secure manner.  (Arguably more secure than

writing the passwords to a file, and definitely more secure

that specifying them on the command line.)



The problem manifest on FreeBSD.  3 is not always a bad fd

on FreeBSD.  I've got a C program that has no problem

closing fd 3 (when fd 3 is properly set up).



Moreover, as I pointed out above, if I call os.fstat (3)

first, then I can os.close (3) without problem.  If 3 was a

bad fd, the call to os.fstat (3) should generate an error. 

It does not.



Please let me know if you have further questions.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-09-10 16:57

Message:
Logged In: YES 
user_id=21627

Why is this a bug? 3 *is* a bad file descriptor, on the

systems which report it to be a bad file descriptor.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=803610&group_id=5470