Bugtraq mailing list archives
Re: bugtraq-digest V1 #68
From: david () shom fr (Ronan David EPSHOM/INF)
Date: Mon, 12 Dec 1994 13:48:28 +0100 (MET)
According to owner-bugtraq-digest () fc net :
bugtraq-digest Sunday, 11 December 1994 Volume 01 : Number 068 ---------------------------------------------------------------------- From: soulet () ecume cict fr (Gilles SOULET) Date: Fri, 9 Dec 1994 10:27:43 +0100 (MET) Subject: SunOS's xterm pb : again ! I sent a message on this list few days ago, and I didn't noticed any real discussion about it. Since I wonder if this topic is still valid (or completly out of date :-), here's what I was talking about : Using Sun's Openwin under SunOS4.1.3, I noticed that the /usr/openwin/bin/xterm wasn't setuid ROOT. It seems to be a good thing (remember the "xterm -lf" + file link bug ?). When you launch an xterm, the system attachs a device to the xterm's shell. You can see this device by typing 'tty' in the xterm's window. OK. The pb is : Under SunOS, the terminal devices (/dev/ttyp?) are owned by root, with rights rw-rw-rw-. When you log on the machine, the login process changes the owner of the terminal, so the tty belongs to you, with minimum access rights. BUT when using an xterm, you don't have the permissions to change the owner and access rights of the newly allocated tty. So the device stays owned by root, WORLD READABLE and WORLD WRITEABLE !!! I think this introduces a major security hole, since everybody can read on a xterm's shell terminal device to get secret informations, including a password ! You can try this by using the "cat" command redirected from (or to) an xterm terminal device : it works ! So what ? # Gillus ~~~~~~~~~~ ------------------------------ From: mc213012 () ci uminho pt (Tiago Faro Lima Pedroso) Date: Fri, 9 Dec 1994 11:31:26 +0100 (MET) Subject: unsubcribe unsubscribe mc213012 () ci uminho pt ------------------------------ From: Justin Mason <jmason () iona ie> Date: Fri, 09 Dec 1994 12:49:22 +0000 Subject: 8lgm's SCO "at" hole [8lgm]-Advisory-10-EXPLOIT describes a hole where a setgid program runs /bin/pwd with popen(3). In case you don't know, this is the way that SunOS, as well as SCO, performs the getcwd() call. Other versions of UNIX may also implement it this way, although Solaris' getwd() doesn't (sorry folks -- don't have enough UNIX machines with trace commands!). trace/truss -f this C code to check: #include <stdio.h> main () { char x[1024]; getcwd(x, 1024); printf ("%s", x); } If you see a fork or vfork, your getcwd runs /bin/pwd. If you have any setuid programs that call getcwd(), make sure they sanitise their environment beforehand. Another thing to watch out for... - --j. ------------------------------ From: roessler () indi5 iam uni-bonn de (Thomas Roessler) Date: Fri, 9 Dec 94 17:45:49 +0100 Subject: Re: Race conditionsFrom: Christopher Samuel <chris () rivers dra hmg gb> Sender: bugtraq-owner () fc net I've just checked this out with a noddy program and built the following table up (appended at the end of this post along with the program). The most suprising part of this exercise for me was that I could only find *one* OS that failed the check and created the file pointed to be the symlink! Must be the pessimist in me.. :) Notes: 1) The program was run as a normal user, not root. 2) The ls output looks like: -rw-r--r-- 1 chris cs2 359 Dec 8 13:46 tst.c lrwxrwxrwx 1 chris cs2 3 Dec 8 14:49 symlink -> ./a -rwxr-xr-x 1 chris cs2 5492 Dec 8 14:50 tst* Happy hunting, folks! Chris -- Christopher Samuel Phone: +44 1684 894644 chris () rivers dra hmg gb N-115, Defence Research Agency, St Andrews Road, Great Malvern, England, UK postmaster () rivers dra hmg gb usenet () rivers dra hmg gb ---------------------------------------------------------- BAD - creates file with "open succeded (fh=3)": HP-UX V7.05 ---------------------------------------------------------- OK - fails with "open: File exists" Ultrix 4.4 Ultrix 4.2 SunOS 4.1.3_U1 SunOS 4.1.3 SunOS 4.1.1 Solaris 2.1 Solaris 2.3 USL SVR4.2 Unixware 1.1.2 SCO 3.2 (ODT3) Irix 5.2 HP-UX 9.05 NeXTstep 3.2 DRS/NX 6000 SVR4 Version 7 Level 2 Increment 2 Linux 1.1.64Well, irix 4.0.5f behaves bad and creates the file. Cheers, Thomas - -- Student at Institute for Applied Mathematics, University of Bonn * Snail mail: Thomas Roessler, Neheimer Weg 1, 51109 Koeln, Germany * INTERNET: roessler () indi5 iam uni-bonn de * BITNET: uzs076 at dbnrhrz1.bitnet * PGP public key info via finger * http://rhein.iam.uni-bonn.de:1025/~roessler If you can't convince them, confuse them. ------------------------------ From: Christopher Samuel <chris () rivers dra hmg gb> Date: Fri, 09 Dec 1994 18:47:47 +0000 Subject: Re: Race conditions In message <9412090137.AA03311 () muggy gg caltech edu>, Walker Aumann <walkera () druggist gg caltech edu> writes:More datapoints on this symlink problem:---------------------------------------------------------- BAD - creates file with "open succeded (fh=3)": HP-UX V7.05HP-UX 8.00thanks!---------------------------------------------------------- OK - fails with "open: File exists"HP-UX V9.05AIX 3.2.3e AIX 3.2.5 DEC-OSF/1 3.0 (I missed them first time around) The full list is in ftp://ftp.dra.hmg.gb/pub/TenDRA/staff/chris/symlinks-problem-list - -- Christopher Samuel Phone: +44 1684 894644 chris () rivers dra hmg gb N-115, Defence Research Agency, St Andrews Road, Great Malvern, England, UK postmaster () rivers dra hmg gb usenet () rivers dra hmg gb ------------------------------ From: rwing!pat () ole cdac com (Pat Myrto) Date: Fri, 9 Dec 94 7:50:36 PST Subject: Re: Race conditions "In the previous message, Jason Matthews said..."On Wed, 7 Dec 1994, Michael Bresnahan wrote:How does one code a suid program so that it evades these problems with symlink race conditions? Is there a way to atomically check if a file is a symlink and open it, or is there another stratedgy?Simply do not use any temporary files...And if a temp file MUST be made, use the mkstemp() call to generate the name and open it. Mkstemp() atomically generates the tempname from the template, opens the file and returns a handle. As the manpage says, mkstemp() eliminates the race condition between testing if a file exists, and the opening of the tmp file. Like mktemp(), mkstemp() uses a template containing six X's, and modifies it in place. Unlike mktemp(), instead of returning a char * pointiong to the string passed to it, mkstemp() returns a file handle to a file open for reading and writing. I haven't tried it with a symlink pointing to a nonexistant file having the name mkstemp() will use initially ('a' and the PID) to see if mkstemp() will fail (or choose another letter, like 'b' in the tempname). That will be an interesting test when I get a few moments.Jason ---------------------------------------------------------------------------- jason () dickory sdsu edu San Diego State University jason () mentor sdsu edu College of Engineering jason () BOOM extern ucsd edu Electrical*Computer Engineering ---------------------------------------------------------------------------- The following email address are no longer valid odn () LoD amaranth com ----------------------------------------------------------------------------- -- pat@rwing [If all fails, try: rwing!pat () eskimo com] Pat Myrto - Seattle WA "No one has the right to destroy another person's belief by demanding empirical evidence." -- Ann Landers, nationally syndicated advice columnist and Director at Handgun Control Inc. ------------------------------ From: fred () nasirc hq nasa gov (Fred Blonder) Date: Fri, 9 Dec 1994 15:19:52 -0500 Subject: Re: Race conditions From: rwing!pat () ole cdac com (Pat Myrto) And if a temp file MUST be made, use the mkstemp() call to generate the name and open it. Mkstemp() atomically generates the tempname from the template, opens the file and returns a handle. As the manpage says, mkstemp() eliminates the race condition between testing if a file exists, and the opening of the tmp file. But 'mkstemp()' is in section 3 of the manual; it's a subroutine, not a system call, so how can it be 'atomic'? ------------------------------ From: Karl Strickland <karl () bagpuss demon co uk> Date: Fri, 9 Dec 1994 21:05:14 +0000 (GMT) Subject: Re: 8lgm's SCO "at" hole[8lgm]-Advisory-10-EXPLOIT describes a hole where a setgid program runs /bin/pwd with popen(3). In case you don't know, this is the way that SunOS, as well as SCO, performs the getcwd() call. Other versions of UNIX may also implement it this way, although Solaris' getwd() doesn't (sorry folks -- don't have enough UNIX machines with trace commands!). trace/truss -f this C code to check: #include <stdio.h> main () { char x[1024]; getcwd(x, 1024); printf ("%s", x); } If you see a fork or vfork, your getcwd runs /bin/pwd. If you have any setuid programs that call getcwd(), make sure they sanitise their environment beforehand. Another thing to watch out for...AFAIK, getcwd(3) always calls /bin/pwd; but getwd(2) is a system call. getcwd() is only provided for backwards compatibility; i suppose all new code should be using getwd(2). - ------------------------------------------+----------------------------------- Mailed using ELM on FreeBSD | Karl Strickland PGP 2.3a Public Key Available. | Internet: karl () bagpuss demon co uk | ------------------------------ From: "Declan A. Rieb" <darieb () sandia gov> Date: Fri, 9 Dec 1994 14:31:21 -0700 (MST) Subject: Re: Race condition The symlink file (./a) was successfully built under A/UX 3.0.2 using Christopher Samuel's "noddy" program. (p.s. "noddy" means what in 'merkun, please?) Declan A. Rieb darieb () sandia gov Sandia National Laboratories, Albuquerque NM 87185-0815 Voice & FAX: (505) 845-8515 ------------------------------ From: jim () Tadpole COM Date: Fri, 9 Dec 1994 16:51:12 -0600 Subject: source to tmpfs fix needed Remember that loadable module that included the tmpfs fix? Does anyone still have it sitting around? I lost my copy. Jim ------------------------------ From: mingus () summit novell com (Marcel-Franck Simon) Date: Fri, 9 Dec 1994 14:55 EST Subject: Novell security advisory on sadc, urestore and the suid_exec feature I am posting this on behalf of Novell Technical Support. Please contact them directly if you have any questions; if you must reply to me, I will forward. ======================================================================= Recently, there were three security advisories posted on the "net" associated with several versions of the Unix Operating System. These advisories are related to the following: /usr/lib/sa/sadc The command is sgid-on-exec to "sys" /usr/sbin/urestore The command is suid-on-exec to "root" suid_exec feature This pertains to "ksh". One of the operating system versions affected was the UnixWare 1.1 product distributed by Novell, Inc. Listed below are the results of the investigation that took place concerning the affected binaries: With respect to the "sadc" problem, the "sadc" binary in the UnixWare 1.1 product has been modified such that it no longer poses a security threat. This modification is provided as PTF683 and is available from Novell Technical Support at (800) 486-4835. With respect to the "urestore" problem, this requires an attribute modification to remove the suid-on-exec bit. The functionality of "urestore" should remain unchanged. This modification is also included in PTF683. The last advisory, suid_exec for ksh, does not apply to the version of "ksh" supplied with the UnixWare 1.1 product. This advisory relates to a feature in "ksh" that allows for the execution of suid-on-exec shell scripts. Since the UnixWare 1.1 product provides this capability in the exec(2) system call in the kernel, the UnixWare 1.1 product does not need to set that DEFINE value when compiling "ksh" to achieve this capability and hasn't since SVR4.0. Novell, Inc. has sent source fixes to all SVR4.0, SVR4.2, and SVR4.2MP OEM customers for both the "sadc" and "urestore" advisories. These vendors should be making them available to licensees of their SVR4.X-based operating systems. If you are using any of the versions mentioned above, you should contact the appropriate vendor to obtain their official update. ------------------------------ From: Steinar Haug <Steinar.Haug () runit sintef no> Date: Sat, 10 Dec 1994 08:30:48 +0100 (MET) Subject: Re: 8lgm's SCO "at" holeAFAIK, getcwd(3) always calls /bin/pwd; but getwd(2) is a system call. getcwd() is only provided for backwards compatibility; i suppose all new code should be using getwd(2).In SunOS 4.1.3 (and 4.1.2) they are both library functions. getcwd() uses popen, as noted. getwd() traverses the path upwards by repeatedly opening the directory on the level above and reading directory entries until it gets a match for the current directory. It uses /etc/mtab to avoid hanging across mount points that might be dead. In HP-UX 9.05 getcwd() traverses the path upwards - it does *not* use popen(). getwd() doesn't exist. POSIX wants you to use getcwd(). Steinar Haug, SINTEF RUNIT, University of Trondheim, NORWAY Email: Steinar.Haug () runit sintef no ------------------------------ From: rwing!pat () ole cdac com (Pat Myrto) Date: Fri, 9 Dec 94 23:32:20 PST Subject: Re: Race conditions "In the previous message, Fred Blonder said..."From: rwing!pat () ole cdac com (Pat Myrto) And if a temp file MUST be made, use the mkstemp() call to generate the name and open it. Mkstemp() atomically generates the tempname from the template, opens the file and returns a handle. As the manpage says, mkstemp() eliminates the race condition between testing if a file exists, and the opening of the tmp file. But 'mkstemp()' is in section 3 of the manual; it's a subroutine, not a system call, so how can it be 'atomic'?I err'd, I was told by another it was atomic. After a bit more research stimulated by your response, I found out that what it does is something like mktemp() to generate an INITIAL tempname, and then tries an open(foo, O_EXCL|O_CREAT|O_RDWR, 0600) on the name (which will fail if a symlink or another file is there). If the open fails, the 'a' preceeding the pid in the tempname that was generated to replace the 6 'X's, gets incremented, and it tries again (with a 'b', 'c', ... prefix) until it succeeds or until the letter prefix has passed 'z'. There is no stat(), lstat(), or fstat() used -- the tempname is created (assuming pid == 12345) with the leading letter 'a' as in a12345, and repeated open()s will try b12345, c12345, etc. If it cannot find a name to use, it will finally return with a value of -1 instead of a file handle. In other words, apparantly the 'atomicity' I was advised about is in the open() call with those options, and used in that way, in its behavior if a file exists, and then changing the name and re-trying again atomically if a file or symlink is seen. Sort of a trial-and-error scheme to find an unused name, selecting a different filename if anything exists by that name. Mkstemp tries to find the name, finding one that is unique at the time it creates it, hands it to the caller, then the caller calls open() on the not-necessarily-unique name some time later. In other words, the test for uniquness on the name actually used is NOT done in the open call. Mktemp() says the name is unique as of some nonzero time previously... In other words, mkstemp() is useful IFF open(x,O_CREAT|O_EXCL|O_whatever,mode) works properly. So, if the OS does NOT support O_EXCL or if it does NOT fail on an open O_RDRW call on a symlink pointing to nothing, one is back to square one. - -- pat@rwing [If all fails, try: rwing!pat () eskimo com] Pat Myrto - Seattle WA "No one has the right to destroy another person's belief by demanding empirical evidence." -- Ann Landers, nationally syndicated advice columnist and Director at Handgun Control Inc. ------------------------------ From: Casper Dik <casper () fwi uva nl> Date: Sat, 10 Dec 1994 14:22:16 +0100 Subject: Re: 8lgm's SCO "at" holeAFAIK, getcwd(3) always calls /bin/pwd; but getwd(2) is a system call. getcwd() is only provided for backwards compatibility; i suppose all new code should be using getwd(2).Neither of the calls is a system call on any system that I'm aware of. Getcwd(3) is the thing POSIX wants you to use. Getwd() is to getcwd() what gets() is to fgets() [ well, almost ]. When chosing between: getwd(char *buf) and getcwd(char *buf, size_t size_of_buf) the choice should be obvious. In SunOS 4.1.x, getcwd() does call /bin/pwd. In Solaris 2.x, getcwd() use /etc/mnttab and some tree traversal to find the current directory. getwd is relegated to libucb.so and just calls getcwd(buf, MAXPATHLEN); Casper ------------------------------ From: Karl Strickland <karl () bagpuss demon co uk> Date: Sat, 10 Dec 1994 13:51:29 +0000 (GMT) Subject: Re: 8lgm's SCO "at" holeAFAIK, getcwd(3) always calls /bin/pwd; but getwd(2) is a system call. getcwd() is only provided for backwards compatibility; i suppose all new code should be using getwd(2).Neither of the calls is a system call on any system that I'm aware of.You're quite right - I stand corrected..Getcwd(3) is the thing POSIX wants you to use. Getwd() is to getcwd() what gets() is to fgets() [ well, almost ]. When chosing between: getwd(char *buf) and getcwd(char *buf, size_t size_of_buf) the choice should be obvious.I'm not so sure its as obvious as the choice between gets() & fgets(). eg: from SunOS 4.1.x getcwd() man page: BUGS Since this function uses popen() to create a pipe to the pwd command, it is slower than getwd() and gives poorer error diagnostics. getcwd() is provided only for compatibility with other UNIX operating systems. So - for me at least - getwd() would be the obvious choice here. getwd() isnt quite as bad as gets() - at least there is an upper bound on getwd() (according to the documentation anyway, obviously not seen the src) of MAXPATHLEN bytes.In SunOS 4.1.x, getcwd() does call /bin/pwd. In Solaris 2.x, getcwd() use /etc/mnttab and some tree traversal to find the current directory. getwd is relegated to libucb.so and just calls getcwd(buf, MAXPATHLEN);Whats getwd() in Solaris 2.x? Does it just do getcwd(pathname, MAXPATHLEN) ? Cheers - ------------------------------------------+----------------------------------- Mailed using ELM on FreeBSD | Karl Strickland PGP 2.3a Public Key Available. | Internet: karl () bagpuss demon co uk | ------------------------------ From: John Nemeth <jnemeth () cue bc ca> Date: Sat, 10 Dec 1994 17:23:52 -0800 Subject: Re: 8lgm's SCO "at" hole On Dec 10, 2:22pm, Casper Dik wrote: } Subject: Re: 8lgm's SCO "at" hole } } Getwd() is to getcwd() what gets() is to fgets() [ well, almost ]. } } When chosing between: getwd(char *buf) and getcwd(char *buf, size_t } size_of_buf) the choice should be obvious. I would have to disagree. fgets() can return any amount of data (potentially GB if connected to a socket or very large file); whereas, getwd() won't return anything bigger then MAXPATHLEN, so buf can be sized appropriately. }-- End of excerpt from Casper Dik ------------------------------ From: "Jonathan M. Bresler" <jmb () kryten Atinc COM> Date: Sat, 10 Dec 1994 20:26:17 -0500 (EST) Subject: Re: Race conditions, mkstemp here is the source for mkstemp from csrg. note the filesystem must support exclusive file locking atomic to the open() for this to be helpful. as is written in the mkstemp() man page. why wasnt O_TRUNC included. that would hammer both soft and hard links Jonathan M. Bresler jmb () kryten atinc com | Analysis & Technology, Inc. | 2341 Jeff Davis Hwy play go. | Arlington, VA 22202 ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346 /* * Copyright (c) 1987 Regents of the University of California. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * This product includes software developed by the University of * California, Berkeley and its contributors. * 4. Neither the name of the University nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ #if defined(LIBC_SCCS) && !defined(lint) static char sccsid[] = "@(#)mktemp.c 5.10 (Berkeley) 2/24/91"; #endif /* LIBC_SCCS and not lint */ #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <errno.h> #include <stdio.h> static int _gettemp(); mkstemp(path) char *path; { int fd; return (_gettemp(path, &fd) ? fd : -1); } char * mktemp(path) char *path; { return(_gettemp(path, (int *)NULL) ? path : (char *)NULL); } static _gettemp(path, doopen) char *path; register int *doopen; { extern int errno; register char *start, *trv; struct stat sbuf; u_int pid; pid = getpid(); for (trv = path; *trv; ++trv); /* extra X's get set to 0's */ while (*--trv == 'X') { *trv = (pid % 10) + '0'; pid /= 10; } /* * check the target directory; if you have six X's and it * doesn't exist this runs for a *very* long time. */ for (start = trv + 1;; --trv) { if (trv <= path) break; if (*trv == '/') { *trv = '\0'; if (stat(path, &sbuf)) return(0); if (!S_ISDIR(sbuf.st_mode)) { errno = ENOTDIR; return(0); } *trv = '/'; break; } } for (;;) { if (doopen) { if ((*doopen = open(path, O_CREAT|O_EXCL|O_RDWR, 0600)) >= 0) return(1); if (errno != EEXIST) return(0); } else if (stat(path, &sbuf)) return(errno == ENOENT ? 1 : 0); /* tricky little algorithm for backward compatibility */ for (trv = start;;) { if (!*trv) return(0); if (*trv == 'z') *trv++ = 'a'; else { if (isdigit(*trv)) *trv = 'a'; else ++*trv; break; } } } /*NOTREACHED*/ } ------------------------------ From: Casper Dik <casper () fwi uva nl> Date: Sun, 11 Dec 1994 14:07:02 +0100 Subject: Re: Race conditions, mkstemphere is the source for mkstemp from csrg. note the filesystem must support exclusive file locking atomic to the open() for this to be helpful. as is written in the mkstemp() man page. why wasnt O_TRUNC included. that would hammer both soft and hard linksBecause it serves no useful purpose. A file created with O_EXCL|O_CREAT will have 0 lenght. If the file needs to be truncated (O_TRUNC) it already exists, but i that case the open w/ O_CREATE|O_EXCL would fail. O_CREATE|O_TRUNC|O_EXCL makes no sense. Casper ------------------------------ From: Casper Dik <casper () fwi uva nl> Date: Sun, 11 Dec 1994 14:15:47 +0100 Subject: Re: 8lgm's SCO "at" holeOn Dec 10, 2:22pm, Casper Dik wrote: } Subject: Re: 8lgm's SCO "at" hole } } Getwd() is to getcwd() what gets() is to fgets() [ well, almost ]. } } When chosing between: getwd(char *buf) and getcwd(char *buf, size_t } size_of_buf) the choice should be obvious. I would have to disagree. fgets() can return any amount of data (potentially GB if connected to a socket or very large file); whereas, getwd() won't return anything bigger then MAXPATHLEN, so buf can be sized appropriately.Almost true, and definitely true for binaries that ship with the system. But lets pick a nit: What happens when some future version of Unix increases the MAXPATHLEN manifest constant? Your application has it compiled in as 1024 (current standard value), but the getwd() routine can return a longer pathname in future. getcwd() will never have such a problem. But agreed, getwd() is currently not a problem. Getcwd is the preferred interface anyway (on modern systems :-) I've only seen something like this break once, bonus points for who can tell why the following is wrong: select(getdtablesize(), &readfds, &writefds, &exceptfds, &timeout); Casper ------------------------------ From: "Jonathan M. Bresler" <jmb () kryten Atinc COM> Date: Sun, 11 Dec 1994 12:20:29 -0500 (EST) Subject: Re: Race conditions, mkstemp (fwd) On Sun, 11 Dec 1994, Casper Dik wrote:here is the source for mkstemp from csrg. note the filesystem must support exclusive file locking atomic to the open() for this to be helpful. as is written in the mkstemp() man page. why wasnt O_TRUNC included. that would hammer both soft and hard linksBecause it serves no useful purpose. A file created with O_EXCL|O_CREAT will have 0 lenght. If the file needs to be truncated (O_TRUNC) it already exists, but i that case the open w/ O_CREATE|O_EXCL would fail. O_CREATE|O_TRUNC|O_EXCL makes no sense. Casperi gotta learn to read the man pages more carefully. there it si at the bottom, in plain view: [EEXIST] O_CREAT and O_EXCL were specified and the file exists. sorry for wasting everyone's time. jmb Jonathan M. Bresler jmb () kryten atinc com | Analysis & Technology, Inc. | 2341 Jeff Davis Hwy play go. | Arlington, VA 22202 ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346 ------------------------------ From: "Christopher A. Stewart" <stewart () networx com> Date: Sun, 11 Dec 1994 15:14:35 +0800 Subject: Re: 8lgm's SCO "at" hole"Casper" == Casper Dik <casper () fwi uva nl> writes:[Stuff deleted] Casper> I've only seen something like this break once, bonus Casper> points for who can tell why the following is wrong: Casper> select(getdtablesize(), &readfds, &writefds, Casper> &exceptfds, &timeout); Casper> Casper Since RLIMIT_NOFILE is not a constant, if a program changes it between the formation of the fdsets and calling it could cause problems, mostly would, if RLIMIT_NOFILE was increased.. - -- - ---------------------------------------------------------------------- Christopher A. Stewart | (Standard disclaimers are in effect) System/Network Administrator | Legent Corp. Networx Div. | Bellevue, Wa. 98004 | Voice (206)-688-2154 | Fax (206)-688-2050 | ------------------------------ End of bugtraq-digest V1 #68 ****************************
Current thread:
- Re: bugtraq-digest V1 #68 Ronan David EPSHOM/INF (Dec 12)
- <Possible follow-ups>
- Re: bugtraq-digest V1 #68 gabi () prometeo cps unizar es (Dec 12)