search for: 5lo

I compiled openssh 3.7.1p1 on Solaris 9 with the Forte compiler in 64-bit mode. After authentication, a forked child of sshd dies with a Bus Error in `read_etc_default_login' (session.c). The reason is the use of `sscanf' with control string "%5lo" on a `mode_t' value. On Solaris in 64-bit mode, `mode_t' is an `unsigned int' (32 bits), whereas `long' is 64 bits. Here is a change that fixed the problem for me. You might want to fix it in cleaner way, however. Regards, Matthias diff -u /home/mkoeppe/s/ATTIC/openssh-3....

I had a problem much like the one that Matthias Koeppe experienced. I would only get the BUS error when running in a YASSP-modified system, though. The binary worked fine on a non-YASSP host. I applied his change to use a long for the mask, and it works now. Cheers, -Thomas __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search

...K=%s in /etc/default/login.\n",var); printf("Reading var for a regular octal value: \n"); sscanf(var, "%5o", &mask); printf("\tUMASK=%o\n",mask); printf("Reading var for a long octal value: \n"); /*** expect a SIGBUS here ***/ sscanf(var, "%5lo", &mask); printf("\tUMASK=%o\n",mask); } ---cut--- This bug is in session.c. It is only exposed AKAIK on 64 bit binaries running on hardened (default umask is set) Solaris boxes. I'm not sure why session.c needs to sscanf a long octal. Can someone try this with Forte compil...

...long mask; > > /* > * We don't want to copy the whole file to the > child's environment, > @@ -936,7 +936,7 @@ read_etc_default_login(char > ***env, u_in > > if ((var = child_get_env(tmpenv, "UMASK")) != > NULL) > if (sscanf(var, "%5lo", &mask) == 1) > - umask(mask); > + umask((mode_t)mask); > > for (i = 0; tmpenv[i] != NULL; i++) > xfree(tmpenv[i]); > __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

I built OpenSSH as a 64-bit binary on Solaris 9, using gcc 3.3.2, OpenSSL 0.9.7c and zlib 1.2.1. sshd starts up normally, and will begin the login session, however, some time after it reads /etc/default/login, it faults and kills the connection. There are no error messages logged to syslog (with LogLevel set to DEBUG) or with the -ddd option. Here's a truss of the failure: 8132:

...ervjnVfzX*i=+i*xvq0!<AapJe zIv)sq9tdsohrS4eE(Ahf20~v2LKg#}OMy^65NZ#GrUgSC!BA%~G(8xa5e&@?hUOtj zH!B#L9SqG0hUNxC$4#Mm!O;9*XhATvFc?|{Nt#28gP|qC(9&RNSunIb7`h`E>I&Wv z<Rsu%Ba(o3BMG=0JMSVf#fOl9ml`C=Y^k8W at 5`j7p}WmIBs5!4p>jhdNfXa*fVc4M z1~EC!+MZ-maY?*$Z<HZ(fF-OhPUwqIv&J at 5LO^CBe5N*3Lb=l#CCOqb%V-0w;lWni ztvebe*-}<tbViB3>i+(;#_+3dh!zLvq|w<ZLN;?Iyss6>o#|LgnH}@=kH_SlJh?DK zFMoe)_)RK*=7{Cb(97RX<<HW~KS1Tr9$Nk^z5F>;enm8y3BLu4LlVR04oy8rPd!hE z=H;uyZxb~0M}%gc4$aF~12hka;)0@#2Pxyi5i>3*&Zt1fMS4Ttp at u9T3fdwav?YzQ zY_|Lj5*TFH^8QMcT-Byo!|y`Q5R*DUqmS8U0WI...