maart@cs.vu.nl (Maarten Litmaath) (12/23/88)
ddl@husc6.harvard.edu (Dan Lanciani) writes: \In article <10845@swan.ulowell.edu>, arosen@hawk.ulowell.edu (MFHorn) writes: \... \| A couple years ago, I had to fix this bug in one of our systems. I had \| source to mkdir.c, but not to the kernel, and was able to successfully \| close the hole completely. Really? \| \| mknod(dirname); /* Irrelevant arguments omitted */ \| link("."); \| link(".."); \| chown(dirname); \| \| The real problem is mkdir trusts dirname to be the directory it just \| created, which is not necessarily the case. Nicing the process only \| shrinks the window of vunlerability, but it doesn't close it. \... \| The proper fix is to change 'chown(dirname);' to 'chown(".");' and \| add a chdir(dirname); in the right place (with proper error checking). \| \| mknod(dirname); \| link("."); \| link(".."); \| chdir(dirname); \| chown("."); Consider the following scheme: mkdir Xmas mknod("Xmas", ...); link("Xmas", "Xmas/."); link("", "Xmas/.."); # scheduled out rmdir Xmas mkdir Xmas mknod("Xmas", ...); # scheduled out cd Xmas ln /etc/passwd . # now the first mkdir is scheduled back in chdir("Xmas"); chown(".", ...); # thanks for the passwdfile! # lots of error messages, but who cares! If John F. Haugh's fix were applied, the scheme above wouldn't work: chown("./.", ...); # error: "." isn't a directory ... unless "." were a symbolic link to another directory. However, I think it very improbable that symbolic links exist on systems WITHOUT the mkdir() system call. The scheme above makes one important thing clear: to gain complete security one must reckon with pathological cases. Two other cookies to be fixed on older systems: mv(1), rmdir(1). The rename() system call wasn't invented for nothing. To Dan Lanciani: could you clarify your ideas by giving a mkdir plot example? -- if (fcntl(merry, X_MAS, &a)) |Maarten Litmaath @ VU Amsterdam: perror("happy new year!"); |maart@cs.vu.nl, mcvax!botter!maart
allbery@ncoast.UUCP (Brandon S. Allbery) (12/31/88)
As quoted from <1849@piraat.cs.vu.nl> by maart@cs.vu.nl (Maarten Litmaath): +--------------- | However, I think it very improbable that symbolic links exist on systems | WITHOUT the mkdir() system call. +--------------- Wrong. I have seen Xenixes and SVR2's which lack mkdir() but have symlink(). It's usually added with some form of networking, for which its use is intended. ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.
david@ms.uky.edu (David Herron -- One of the vertebrae) (12/31/88)
In article <13306@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >As quoted from <1849@piraat.cs.vu.nl> by maart@cs.vu.nl (Maarten Litmaath): >+--------------- >| However, I think it very improbable that symbolic links exist on systems >| WITHOUT the mkdir() system call. >+--------------- Wrong .. at some point AT&T started preparing SysV for integration of BSD stuff. At (at least) SysVr3.1 the Official sources had symlink() as well as the vnode stuff and a few other "berkeleyisms". -- <-- David Herron; an MMDF guy <david@ms.uky.edu> <-- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <-- Now I know how Zonker felt when he graduated ... <-- Stop! Wait! I didn't mean to!
liz@grian.cps.altadena.ca.us (Liz Allen-Mitchell) (01/01/89)
Why does mkdir() make the directory with root ownership in the first place? Why can't it create the node as owned by the user calling mkdir in the first place? Other side of the question: Why doesn't this hole appear when files are created? Or does it?!? -- - Liz Allen-Mitchell liz@grian.cps.altadena.ca.us ames!elroy!grian!liz "God is light; in him there is no darkness at all." -- 1 John 1:5b