Date: Tue, 2 Aug 2005 10:28:25 -0700 From: Brooks Davis <brooks@one-eyed-alien.net> To: diz@linuxpowered.com Cc: freebsd-hackers@freebsd.org, vd@datamax.bg Subject: Re: [patch] rc.d/tmp (silly mkdir usage) Message-ID: <20050802172825.GA19107@odin.ac.hmc.edu> In-Reply-To: <1711.68.95.232.238.1123001239.squirrel@68.95.232.238> References: <51934.68.95.232.238.1122957425.squirrel@68.95.232.238> <20050802062937.GA31485@sinanica.bg.datamax> <1711.68.95.232.238.1123001239.squirrel@68.95.232.238>
next in thread | previous in thread | raw e-mail | index | archive | help
--X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 02, 2005 at 11:47:19AM -0500, diz@linuxpowered.com wrote: > > On Mon, Aug 01, 2005 at 11:37:05PM -0500, diz@linuxpowered.com wrote: > >> Howdy hackers, > >> > >> I'm sorry for the previous patch, so here is at least one item that > >> really > >> bugs me that isn't obfuscation. In short, I don't see any reason to fo= rk > >> some process to simply "touch" a file (is a filesystem writable) when > >> built-in shell i/o does this: > >> > >> --- /etc/rc.d/tmp.orig Mon Aug 1 23:20:24 2005 > >> +++ /etc/rc.d/tmp Mon Aug 1 23:22:07 2005 > >> @@ -48,8 +48,8 @@ > >> [Nn][Oo]) > >> ;; > >> *) > >> - if (/bin/mkdir -p /tmp/.diskless 2> /dev/null); then > >> - rmdir /tmp/.diskless > >> + if ( > /tmp/.diskless 2> /dev/null); then > >> + rm /tmp/.diskless > >> else > >> if [ -h /tmp ]; then > >> echo "*** /tmp is a symlink to a non-writable > >> area!" > >> > > > > The thing you suggest is bloody insecure. Just imagine some baduser > > doing ln -s /etc/passwd /tmp/.diskless before rc.d/tmp gets executed. > > I guess this is the reason why directory creation is used instead of > > file creation. >=20 > Well these notions have nothing todo with the way it works, but they are > interesting still. I would imagine a dir could be linked too if somebody > managed to insert a rc.d script in that was ordered sufficiently early > enough to do the evil tasks you are thinking about. Even if mktemp(1) were > available at this stage, I wouldn't use it here. No, mkdir won't act through the link so it's the best option here: $ rm nonexistant $ ls nonexistant ls: nonexistant: No such file or directory $ ln -s nonexistant n1 $ mkdir n1 mkdir: n1: File exists $ ls nonexistant ls: nonexistant: No such file or directory $ > n1 $ ls n1 n1 $ ls nonexistant nonexistant $ echo foobar >> nonexistant $ cat nonexistant foobar $ > n1 $ cat nonexistant $ mkdir n1 mkdir: n1: File exists $ > > I just wonder why a new shell is forked for this test. Simply > > if /bin/mkdir -p /tmp/.diskless 2> /dev/null ; then > > would do the same thing without forking a new shell that only executes > > /bin/mkdir >=20 > Let me be clear about this, the ONLY reason mkdir is used here is because > touch is under /usr somewhere which isn't even mounted at this point > (assuming /usr is mounted seperatly, as is the case on nfs diskless > systems). So we are left with what is availabile in /bin, /sbin, /rescue. > Therefore mkdir was used as a work-around. What I'm saying is this entire > thought process is overly-engineered when the shell can simply "touch" a > file with stdout or stderr. This is indeed the most minor of > optimizations. Nope. $ rm nonexistant $ touch n1 $ ls nonexistant nonexistant -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFC7602XY6L6fI4GtQRAsYfAJ95VzuMq+d2Nkik+fKBAnhe5QP/zwCcDroa MaQuqIZp3hgBELHrm36ODEI= =7ssP -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050802172825.GA19107>