This was found in a code sweep associated with the OpenSolaris bug:
6346809 S_IFxxx is not a bitmask but our programmers don't know
(http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6346809)
The issue is there are a few places where OpenSSL uses the st_mode field
of "struct stat" as a bit mask when it isn't.
The patch below was generated against 0.9.8a (but is still relevant for
0.9.8k and higher?).
Thanks,
-Mark
diff -ruN openssl-0.9.8a/apps/ca.c openssl-0.9.8a/apps/ca.c
--- openssl-0.9.8a/apps/ca.c 2005-09-30 18:47:15.000000000 +0200
+++ openssl-0.9.8a/apps/ca.c 2009-03-26 17:27:26.364972087 +0100
@@ -858,8 +858,8 @@
perror(outdir);
goto err;
}
-#ifdef S_IFDIR
- if (!(sb.st_mode & S_IFDIR))
+#ifdef S_ISDIR
+ if (!S_ISDIR(sb.st_mode))
{
BIO_printf(bio_err,"%s need to be a
directory\n",outdir);
perror(outdir);
diff -ruN openssl-0.9.8a/crypto/rand/randfile.c
openssl-0.9.8a/crypto/rand/randfile.c
--- openssl-0.9.8a/crypto/rand/randfile.c 2005-05-21 19:39:52.000000000
+0200
+++ openssl-0.9.8a/crypto/rand/randfile.c 2009-03-26 17:28:39.081971620
+0100
@@ -110,8 +110,8 @@
in=fopen(file,"rb");
if (in == NULL) goto err;
-#if defined(S_IFBLK) && defined(S_IFCHR)
- if (sb.st_mode & (S_IFBLK | S_IFCHR)) {
+#if defined(S_ISBLK) && defined(S_ISCHR)
+ if (S_ISBLK(sb.st_mode) || S_ISCHR(sb.st_mode)) {
/* this file is a device. we don't want read an infinite number
* of bytes from a random device, nor do we want to use buffered
* I/O because we will waste system entropy.
@@ -153,8 +153,8 @@
i=stat(file,&sb);
if (i != -1) {
-#if defined(S_IFBLK) && defined(S_IFCHR)
- if (sb.st_mode & (S_IFBLK | S_IFCHR)) {
+#if defined(S_ISBLK) && defined(S_ISCHR)
+ if (S_ISBLK(sb.st_mode) || S_ISCHR(sb.st_mode)) {
/* this file is a device. we don't write back to it.
* we "succeed" on the assumption this is some sort
* of random device. Otherwise attempting to write to
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]