🚀 go-pugleaf

In article <1992Dec9.091253.26269@informix.com> (Colonel Panic) writes:
|> I've run into a nasty bug on NCR, but I can't yet be sure whether this
|> is a USL-generic thing or NCR-specific.


Well, to prove it a "nasty bug on NCR", I think you will have to explain
a bit closer what you are doing.  See below.


|> 
|> The scenario: I have a socket-accepting daemon that forks children for
|> each new accepted connection over an RF link.  Pretty basic stuff.
|> At one point, I call putenv() to replace PATH in the user's environment
|> (a security measure; long story).  I assemble my new variable into a



Do you replace with a fixed string or with an edited version of the
current PATH. If last mentioned is the case, try running your application 
with a small path like

	PATH=/tmp;.    YourApplication

 
|> (static) character buffer declared above main (*not* an automatic
|> variable, I'm not *quite* that punchy yet), call putenv(), putenv()
|> returns zero, AND CLOBBERS MY SOCKET HANDLE! (a (static) int). 


Is the socket handle declared right after your buffer, and if not
are variables between them clobbered too? From below we already know,
that stuff behind your socket handle variable must have been clobbered.


|> What was (5) becomes (1835413345) as an immediate result of the putenv(). 
|> 

Have you noticed, that 1835413345 = 0x6d662f61 = "mf/a" ?
With an Intel based machine meaning, that your path contains substring 
"a/fm". If you dump the bytes behind the socket handle variable you would
probably find the rest of the path. At the very least you will find the Null
byte ending this string.

putenv will never try to write to your string variable. Uses only the pointer
parameter you give it. As specified by the man-page for putenv
it manipulates the environment pointed to by "environ". A simple
table of string pointers. Of which one of them is yours.

Without a testprogram showing this, I must admit, that this seem
a classic case of a couple of "strcat"s running wild to me. Simple
overwrite.  Working with PATH values, you should take extreme care
of the size of the buffers. You can never assume anything about the size
of the PATH used by your end users. It may work fine in your environment
with a fixed size buffer, but tomorrow you are delivering your product to a
customer with a very wild and long PATH variable. Unless you are willing to
preallocate wiiillldddd buffersizes; work dynamic... Never trust users. :-))



|> The string being putenv'd is about 340 bytes long.  I don't know yet 
|> if anything else gets clobbered.



As seen from above I would think thats what you would expect.



|> 
|> All of this works fine on Sun and HP/UX (among others), but this is
|> the first SVR4 we've tried it on.   
|> 
|> Any ideas out there?
|> 
|> Version info:
|> cat /etc/.relid
|> 051992 RELEASE 010300 Prerelease Version 04 NST OS
|> uname -a
|> ncr486 ncr486 4.0 2.0 3314 386/486/MC



All the above is NCR specific info, and will not mean anything
to people outside NCR. Unfortunately. :-()

The above is a 4.0.x equivalent.

	Hope this helps, Mr. Panic. :-))

		Bo

-- 
Bo Asbjorn Muldbak             // Email:  Bo.Muldbak@ColumbiaSC.NCR.COM
Unix Systems Business Unit     // Phone:  +1 (803) 791-6871
NCR Corporation, MCPD-Columbia // Fax  :  +1 (803) 739-7371
All standard disclaimers apply // Wizards? Where, when, why? I'm an atheist..