> -----Original Message----- > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Michael Wojcik > Sent: Thursday, January 22, 2015 11:34 PM > To: openssl-users at openssl.org > Subject: Re: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes > failure on AIX, warning on all others > > > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > > Behalf Of Salz, Rich > > Sent: Thursday, January 22, 2015 16:37 > > To: openssl-users at openssl.org > > Subject: Re: [openssl-users] missing default > > /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all > > others > > > > > I can't. The behavior of fopen is defined by ISO 9899 and the Single > > > UNIX Specfication, which AIX has adhered to for well over a decade. > > > > I meant no disrespect to big blue :) I worked there for a > > half-decade, and also with them on standards for a lot longer... > > > > > int main(void) {fopen("/usr/local/ssl/openssl.cnf", "rb"); > > > perror("fopen"); > > > > And what happens if some of the directories on the path don't exist? > > Depends on which of the following happens first: > > - open(2) encounters a missing directory: ENOENT. > - open(2) encounters a non-traversable directory: EACCES. (I wrote "EPERM" > in an earlier note, but I don't think that's even a real errno value name. Duh.) > - open(2) gets all the way to the file but doesn't have sufficient permission: > ENOENT. > - Some other I/O error occurs (broken NFS mount, etc): some other errno > value, or possibly a hang, eg in the case of some NFS mounts. SUSv3 lets > fopen set EACCES, EINTR (if open is "slow" and gets interrupted by a signal), > EISDIR, ELOOP, EMFILE, ENAMETOOLONG, ENFILE, ENOENT, ENOSPC (should > only happen for file creation), ENOTDIR (if you have a non-directory as a non- > terminal path component), ENXIO (trying to open a special node in an > unsupported way), EOVERFLOW, EROFS, EINVAL, ENOMEM, and ETXTBSY. > > A quick look at apps/openssl.c suggests that it'll abort if it gets anything other > than CONF_R_NO_SUCH_FILE from > ERR_GET_REASON(ERR_peek_last_error()) after NCONF_load fails. That > doesn't clarify things much, though I'd suggest that it might be worth > suppressing this behavior via an option. This reminds me of http://rt.openssl.org/Ticket/Display.html?id=2644&user=guest&pass=guest , though it's in another code path ... Over time I met at least 4 other people who ran into exactly this issue on Windows, so if I'd have any votes to give to a bug report, it would be this one :) Regards Kai
