Received: (qmail 27797 invoked by uid 2012); 4 Nov 1997 23:10:27 -0000 Message-Id: <19971104231027.27796.qmail@hyperreal.org> Date: 4 Nov 1997 23:10:27 -0000 From: Roy Wood Reply-To: roywood@unn.unisys.com To: apbugs@hyperreal.org Subject: Server incorrectly interprets whether file is a symlink. X-Send-Pr-Version: 3.2 >Number: 1357 >Category: os-unixware >Synopsis: Server incorrectly interprets whether file is a symlink. >Confidential: no >Severity: serious >Priority: medium >Responsible: jim >State: closed >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Tue Nov 4 15:20:00 PST 1997 >Last-Modified: Mon Mar 15 10:17:19 PST 1999 >Originator: roywood@unn.unisys.com >Organization: >Release: 1.2.4 >Environment: Unixware 2.1.2 Unixware C compiler >Description: The Unixware lstat function is broken when server is compiled with _POSIX_SOURCE defined. The last access time is incorrectly used to determine whether the file is a symlink. >How-To-Repeat: Compile with _POSIX_SOURCE defined. The last accessed time is used to determine whether file is a symlink based on: (T=file type field) xxxxTxxx >Fix: Remove define of _POSIX_SOURCE in UW case of conf. >Audit-Trail: From: Dean Gaudet To: apbugs@apache.org Cc: Subject: Re: os-unixware/1357: Server incorrectly interprets whether file is a symlink. (fwd) Date: Sat, 7 Feb 1998 04:17:42 -0800 (PST) ---------- Forwarded message ---------- To: Dean Gaudet Subject: Re: os-unixware/1357: Server incorrectly interprets whether file is a symlink. (fwd) From: Tom Hughes Date: 22 Jan 1998 08:43:12 +0000 Lines: 46 In article , Dean Gaudet writes: > I wonder if you could do us a favour and help us with this PR? Since you > seem to be familiar with unixware I thought I'd give you a try :) I'm happy to try and help but I will admit to being a bit baffled by it at the moment... It is true that sys/stat.h on Unixware 2 is a little odd as it sometimes causes little static functions to be included as veneers. In fact lstat is one of these cases when _POSIX_SOURCE is defined. Specifically, without it you get this: #define lstat(p,b) _lxstat(_STAT_VER, p, b) and with it you get this: static int lstat(const char *path, struct stat *buf) { int ret; ret = _lxstat(_STAT_VER, path, buf); return ret; } Those look like they should be equivalent to me though so I don't understand why they are both there unless POSIX requires lstat() to be a real function perhaps? Besides which it still doesn't explain the bug or why the server should look at the wrong part of the struct... What we really need is a test case - a file whose attributes are such that it is misidentified as a link. > If you want to see the current state of 1.3b4-dev with your patch applied > you'll be able to grab it in a few hours from > . I'll grab a copy tonight and see what I make of it tomorrow. Tom -- Tom Hughes : thh@cyberscience.com : tom@compton.demon.co.uk Software Engineer, Cyberscience Corporation Rawdon House, High Street, Hoddesdon, Hertfordshire EN11 8BD ... Logic is the art of going wrong with confidence State-Changed-From-To: open-analyzed State-Changed-By: dgaudet State-Changed-When: Sat Feb 7 04:21:28 PST 1998 State-Changed-Why: I'm really confused by this. We don't have anyone who uses unixware, so we can't really test out your suggestion. Are you sure this doesn't affect anything else? Have you tried building all the modules without _POSIX_SOURCE ? Will it work on all 2.x versions of unixware? Thanks Dean From: "Roy Wood" To: dgaudet@hyperreal.org Cc: Apbugs@Apache.Org, Apache-Bugdb@Apache.Org, Dgaudet@Apache.Org Subject: Re: os-unixware/1357: Server incorrectly interprets whether file is a symlink. Date: Thu, 19 Feb 1998 11:24:13 -0500 --0__=pQJFBByXqzan73O8nbCZfsZ8Yqf26DdBkfzEro5oQQukAX4p7Krwmumn Content-type: text/plain; charset=us-ascii I am sorry it took so long to get back to you (so much to do, so little time). I don't think compiling without _POSIX_SOURCE defined affects anything else. We have been running with this change since I submitted it. We are running Stronghold 2.1 with all modules compiled without the _POSIX_SOURCE defined. We are running Unixware 2.1.2. I am assuming that this bug exists in all 2.1 releases. We tried to report the bug and get it fixed through Unisys/Unixware but we were told that the stat function wasn't part of the POSIX spec that they coded to and we were out of luck. Our argument that it was obviously broken and existing fuctions shouldn't break fell on deaf ears. I am enclosing the results of a test program we ran to troubleshoot the problem. Compiling with _POSIX_SOURCE defined causes the stat function to return the time rather than the file type. Depending on the time the function was called determines whether the function thinks the file is a link or not (real fun to figure out). If you have any other questions, please let me know. Regards, Roy Wood Script started on Thu Feb 19 09:49:06 1998 IH19:/work/acct/roy/src>cat Makefile PROGRAM =linktest CFLAGS = -g \ -DCOMPILED=\"`date +%D_%T`\" #CFLAGS = -g \ # -D_POSIX_SOURCE -DCOMPILED=\"`date +%D_%T`\" OBJS = linktest.o $(PROGRAM): $(OBJS) cc $(OBJS) $(CFLAGS) -o $(PROGRAM) linktest.o: linktest.c all: make $(PROGRAM) clean: rm -f *.o core.* IH19:/work/acct/roy/src>cat linktest.c #include #include #include main(argc,argv) int argc; char **argv; { struct stat x_stat; if(!lstat(argv[1], &x_stat)) { printf("Good stat of file \"%s\"\n", argv[1]); printf("st_atime=%0x\n", x_stat.st_atime); printf("st_mode=%0x\n", x_stat.st_mode); printf("st_xmode0=%0x\n", *((int *)((char *)(&x_stat) + 0))); printf("st_xmode4=%0x\n", *((int *)((char *)(&x_stat) + 4))); printf("st_xmode8=%0x\n", *((int *)((char *)(&x_stat) + 8))); printf("st_xmode12=%0x\n", *((int *)((char *)(&x_stat) + 12))); printf("st_xmode16=%0x\n", *((int *)((char *)(&x_stat) + 16))); printf("st_xmode20=%0x\n", *((int *)((char *)(&x_stat) + 20))); printf("st_xmode24=%0x\n", *((int *)((char *)(&x_stat) + 24))); printf("offset=%d\n", ((int)(&((struct stat *)NULL)->st_mode))); } else { printf("Bad stat of file \"%s\"\n", argv[1]); } } IH19:/work/acct/roy/src>make clean rm -f *.o core.* IH19:/work/acct/roy/src>make cc -g -DCOMPILED=\"`date +%D_%T`\" -c linktest.c cc linktest.o -g -DCOMPILED=\"`date +%D_%T`\" -o linktest IH19:/work/acct/roy/src>linktest link Good stat of file "link" st_atime=34ec51f6 st_mode=a1ff st_xmode0=88020c st_xmode4=0 st_xmode8=0 st_xmode12=0 st_xmode16=24d st_xmode20=a1ff st_xmode24=1 offset=20 IH19:/work/acct/roy/src>make clean rm -f *.o core.* IH19:/work/acct/roy/src>make cc -g -D_POSIX_SOURCE -DCOMPILED=\"`date +%D_%T`\" -c linktest.c cc linktest.o -g -D_POSIX_SOURCE -DCOMPILED=\"`date +%D_%T`\" -o linktest IH19:/work/acct/roy/src>linktest link Good stat of file "link" st_atime=7fffffff st_mode=34ec51f6 st_xmode0=24d3206 st_xmode4=1a1ff st_xmode8=c9040a st_xmode12=0 st_xmode16=5 st_xmode20=34ec51f6 st_xmode24=34ec5158 offset=20 IH19:/work/acct/roy/src>exit script done on Thu Feb 19 09:51:30 1998 (Embedded image moved dgaudet@hyperreal.org to file: 02/07/98 06:21 AM PIC30119.PCX) To: apache-bugdb@apache.org, dgaudet@apache.org, Roy Wood/GCS/US/Unisys cc: Subject: Re: os-unixware/1357: Server incorrectly interprets whether file is a symlink. [In order for any reply to be added to the PR database, ] [you need to include in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] Synopsis: Server incorrectly interprets whether file is a symlink. State-Changed-From-To: open-analyzed State-Changed-By: dgaudet State-Changed-When: Sat Feb 7 04:21:28 PST 1998 State-Changed-Why: I'm really confused by this. We don't have anyone who uses unixware, so we can't really test out your suggestion. Are you sure this doesn't affect anything else? Have you tried building all the modules without _POSIX_SOURCE ? Will it work on all 2.x versions of unixware? Thanks Dean --0__=pQJFBByXqzan73O8nbCZfsZ8Yqf26DdBkfzEro5oQQukAX4p7Krwmumn Content-type: application/octet-stream; name="PIC30119.PCX" Content-transfer-encoding: base64 CgUBCAAAAABoACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABaQABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPH E8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sT zRPHE8MTwhPwEwzIBgzYE8wTxhPDE8IT7hPOBtcTzBPGE8MTE+wTwgbCBwbCEgbCEgbCEsUG1hPL E8YTwxMT6hMMwgYHwgLCAwISwgfEEsMCwwbVE8sTxRPDExPpE8MGAwcCBwMCwhLDB8ISwgISwgLD BtUTyhPFE8MTE+gTwgIHA8ICEw4DDgLDE8USwwLCEMIG1BPKE8UTwxMT5xMCAwcDAg4TDgITwgIS D8ISD8ISBRICEcICwwbUE8oTxRPCExPmEwYCBwMCDgIOwgLDExITEhPCEg8GxgLDBtMMDAfJE8QT whMT5hMGwwITBgMCDhLFEw8SE8ISBgIDwhIDEsMGB9MDxwwHxRPDExPlEwYHAhESAg8CwhMPwhMP xBMPxRIQwgIDAgMCBtMDxwPEDAfDE8IT4RMHwwzCBgLCEhMCDxLIE8MSD8MSwwIQAwIDBgfSDMkD wgPCDAfCExPbEwfGDMIDDAIHERITEhMSwxMPwxMPwxPDEgIDAgMCwwMCBgzREwfHDMYDDMITE9YT B8UMyAMGB8ICBhLDAsYTEhMSExIPwhIHAgcCAwUQAgYRBgfSE8UTB8QMwgMMwhMT0hMHxAzLA8IM BsISDxESExITAw4DxBMSExITwxICBwPCAsMDDMIGB9ITyRMHwwzCExPPEwfDDMkDxQwHwhMGBxIT AhECEwMOAg7DExITDxMPwxIDAgMCBwMCDAYRBgfSE8kTwhPCDMITE8wTB8MMxwPEDMIHxxMGxBLD Ag4DDgIGwg/IEgIDwgIDAgwCEMIGB9ITyRMHDAcMwhMTyhMHwgzGA8MMwgfMEwYHwhLCEAIOAg4C DhDDAhIPxhIFAgXDAgUCEQYH0hPHEwfCDAcPDMITE8gTB8IMxQPDDAfQEwbDEhDEAhAOEA4QwgLG EgcSBhIGBcMCBcIGB9ATB8UMEwfCDA8HDwwHwhMTxhMHwgzEA8MMB9MTBgfCEhADEMICDhAOEMIC EQIDxxIGBwbCAgUCEQYHyxMHxAwHwhMHEwzCEwcPBw8MB8MTE8UTBwzEA8IMB9YTBsQSEAMCA8UC EQIDAgPDEgcSBgfCBgUQAhDCBgfGEwfEDAfGE8INEwzCEw8HwgwHwxPCE8QTBwzDA8IMB9gTBgfE EhACEMYCEQIDAsQSBhLDBsICEALCBgfCEwfDDAfKEwfCDRMHwhPCDAfEE8ITE8MTBwzCA8IMB9oT DBIHwxLDDBEDxQIDAgPDEgYSBgfCBgIQAhAGDAfCEwzDE8MHyRMHwhPCBxMHxRPDExPDEwzCAwwH 3RMGxxICEQPDAgMCA8MSBhIGBwYMBhACEAIGDMMTDBPCB8YTwwfHEwfGE8MTwhPDEwwDDAfeEwYH xxICEQPDAgMCwhIGEgYHBgwGEAIQAsIGB8MTDMYTwwfKEwzGE8MTwhPDE8IMB98TDBLCB8USAgMR xAISB8ISBgcGDAYQBhAGEAYMB8MMB8kTwwfHEwzGE8MTwhPDEwwPwgzfEwYSB8ISB8ISAhECAwID EgcSBwYHBgwGEAYQxgzDD8IHxRPDB8kTBwzGE8MTwhPDEwzDD8QM3BPCBhIGwxIGAhECAwIHBgcG yAzJDxMHzRMHwwwHxxPDE8ITwxMHDMYPxwwH1BMGEgYSBhLLDM4PwwwTDMcTwgfEDAfJE8QTwhMT xBMHwgzLD9sM0w/GDAfDEwzDEwfEDAfLE8YTwxMTxhMHxAztD8gMBgfIE8QMB84TxxPDE8ITyhMH xwzbD8sMEAUMBcIMwgYH1RPKE8UTwxMT0RMH2wwGEAYQBhACBQwFDAUMBgwHBgfWE8sTxRPDExPu EwYMBhAGEAIGDAYMwwYH1xPLE8YTwxMT8BPKBgfYE8wTxhPDExP1E9sTzRPHE8MTwhP1E9sTzRPH E8MTwhMMAAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD/ /wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8A AAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A //8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAA AP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA /wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCk gICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vw oKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw //vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzA psrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDA wNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICA wMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACA AICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACA gACA//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP////// --0__=pQJFBByXqzan73O8nbCZfsZ8Yqf26DdBkfzEro5oQQukAX4p7Krwmumn-- Responsible-Changed-From-To: apache-jim Responsible-Changed-By: dgaudet Responsible-Changed-When: Fri Feb 27 01:24:30 PST 1998 Responsible-Changed-Why: Hey Jim looks like we need to remove _POSIX_SOURCE for most versions of unixware... I asked one of the other unixware folks and they confirmed it's fine to remove it State-Changed-From-To: analyzed-closed State-Changed-By: jim State-Changed-When: Mon Mar 15 10:17:19 PST 1999 State-Changed-Why: closed >Unformatted: