apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gang Shu <gangsh...@gmail.com>
Subject RE: Bugs discovered by a research group at CWRU
Date Thu, 20 Aug 2009 21:57:41 GMT
Dear Apache Portable Runtime (APR) developers:

Thanks a lot for your quick and kind reply. Your feedback are really helpful
to us for improving the accuracy of our method.



*For 1: *

We agree with your reply that it should not be a bug.



*For 2: *

We are trying to understand this problem in the following way. In the file
"file_io/unix/open.c", since there exists the codes (line 166 to 180) which
have already set FD_CLOEXEC if APR_FOPEN_NOCLEANUP was not set, so the codes
(line 214 to 218) do not have bugs.



Filename: file_io/unix/open.c, Function: apr_file_open()

166    if (!(flag & APR_FILE_NOCLEANUP)) {

167        int flags;

168

169        if ((flags = fcntl(fd, F_GETFD)) == -1)

170            return errno;

171

172        flags |= FD_CLOEXEC;

173        if (fcntl(fd, F_SETFD, flags) == -1)

174            return errno;

175    }

.....

179    (*new)->flags = flag;

180    (*new)->filedes = fd;

.....

214    if (!(flag & APR_FILE_NOCLEANUP)) {

215        apr_pool_cleanup_register((*new)->pool, (void *)(*new),

216                                  apr_unix_file_cleanup,

217                                  apr_unix_child_file_cleanup);

218    }



* *

*For 3: *

Besides the possible bug 3.1 we mentioned in the last email, we have found a
similar problem 3.2 as well.

According to the bug-fix pattern in the function “apr_file_mktemp()”, we
think that APR may also set “flags |= FD_CLOEXEC” (line 279 to 290) under
the condition of “#ifndef HAVE_ACCEPT4” in the functions “apr_os_sock_make()”
and “apr_os_sock_make()”.



**************************original bug-fix**********************************



Filename: file_io/unix/mktemp.c, Function: apr_file_mktemp()



176 apr_status_t apr_socket_accept(apr_socket_t **new, apr_socket_t *sock,

177                                apr_pool_t *connection_context)

………

195     alloc_socket(new, connection_context);

……..

276         (*new)->local_interface_unknown = 1;

277     }

278

279 + #ifndef HAVE_ACCEPT4

280 +    {

281 +           int flags;

282 +

283 +           if ((flags = fcntl((*new)->socketdes, F_GETFD)) == -1)

284 +               return errno;

285 +

286 +           flags |= FD_CLOEXEC;

287 +           if (fcntl((*new)->socketdes, F_SETFD, flags) == -1)

288 +            return errno;

289 +       }

290 +   #endif

291

292     (*new)->inherit = 0;



**************************discovered possible new bug(s)***********************



(3.1) Filename: network_io/unix/sockets.c, Function: apr_os_sock_make()



411 apr_status_t apr_os_sock_make(apr_socket_t **apr_sock,

412                               apr_os_sock_info_t *os_sock_info,

413                               apr_pool_t *cont)

414 {

415     alloc_socket(apr_sock, cont);

……..

439     else {

440         (*apr_sock)->remote_addr_unknown = 1;

441     }

(///We think here may exist a potential bug///)

442

443     (*apr_sock)->inherit = 0;





(3.2) Filename: network_io/unix/sockets.c, Function: apr_os_sock_put ()



449 apr_status_t apr_os_sock_put(apr_socket_t **sock, apr_os_sock_t
*thesock,

450                            apr_pool_t *cont)

451 {

452     /* XXX Bogus assumption that *sock points at anything legit */

453     if ((*sock) == NULL) {

454         alloc_socket(sock, cont);

455         /* XXX IPv6 figure out the family here! */

456         /* XXX figure out the actual socket type here */

457         /* *or* just decide that apr_os_sock_put() has to be told the
family and type */

458         set_socket_vars(*sock, APR_INET, SOCK_STREAM, 0);

459         (*sock)->timeout = -1;

460    }

461    (*sock)->local_port_unknown = (*sock)->local_interface_unknown = 1;

462    (*sock)->remote_addr_unknown = 1;

463    (*sock)->socketdes = *thesock;

(///We think here may exist a potential bug///)

464    return APR_SUCCESS;

465 }







In our research, we analyzed some of your fixed bugs to build up a bug
pattern database, and then tried to
find out whether there are similar bugs left in the codes. Since all of
these possible bugs are found by a set of automatic system, it is hard to
say we have understood your codes completely. This is the reason we just
indicate where there may exist a bug but not submit patches.



Thank you very much for your precious time!



Sincerely,

Gang Shu



Computer Science Division, EECS

513 Olin Building

Case Western Reserve University

10900 Euclid Avenue

Cleveland, OH 44106

Email: gang.shu@case.edu









-----Original Message-----
From: Bojan Smojver [mailto:bojan@rexursive.com]
Sent: Thursday, August 20, 2009 3:14 AM
To: Jack Andrews
Cc: Gang Shu; dev@apr.apache.org
Subject: Re: Bugs discovered by a research group at CWRU (2)



On Thu, 2009-08-20 at 17:08 +1000, Jack Andrews wrote:

> i think he's asking us to confirm or deny patterns that he has

> found that could indicate another bug that has a similar

> fix to a bug that was fixed previously.



Yeah, something like that:

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

It would be greatly appreciated if you can reply to this email after you

have gone over the bugs and tell us whether you have confirmed any of

them, since these information are really valuable for us for testing our

current method.

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



So, for 1, I'm saying most likely not a bug. For 2, I'm saying also most

likely not a bug (although I initially thought there may be a problem,

because I keep thinking of fork() when someone says exec()). For 3, I'm

too confused to respond.



The reason I asked for patches is that if there is potential bug, then

obviously there is a potential fix. Usually, it's a bit easier to read

what is being fixed by reading the actual fix.



-- 

Bojan

Mime
View raw message