Date: Thu, 12 Feb 1998 20:04:04 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: eivind@yes.no (Eivind Eklund) Cc: owensc@enc.edu, freebsd-hackers@FreeBSD.ORG, braam@cs.cmu.edu Subject: Re: Coda FS: FBSD port done!, but development favors Linux Message-ID: <199802122004.NAA20960@usr02.primenet.com> In-Reply-To: <19980212185933.22479@follo.net> from "Eivind Eklund" at Feb 12, 98 06:59:33 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> And ext2fs is AFAIK only faster due to the default blocksize and the > fact that they violate a patented Novell technology. (Terry can say > more on this; they either violate DOW-patents or run unsafe; I forget > which...) This is false; the only people who use DOW are USL, AFAIK. DOW is inferior to Soft Updates to the same degree that the Banker's algorithm is inferior to Warshall's transitive closure algorithm for concurrency. I do *NOT* believe Linux is in violation of any patents in ext2fs; this is my professional opinion, and I'm willing to testify to it in court, if Linux needed me to do so. The default setting for ext2fs is to run async, which is provably (in the mathematical sense) unsafe. At least it's probable to people who understand math. 8-). So ext2fs does *run* unsafe. But it's not fair to say that it *is* unsafe; you can turn on sync, and ext2fs will be as safe as FFS (by default, FFS sets "doingasyncfree" to "on", which is just as dangerous as ext2fs's technique; if you turn this off, FFS is safer, but slower, than ext2fs. Leave it alone, and they are very comparable). [ ... good security discussion on flat inode namespaces ... ] See my other posting. There is already an implementation of this for FreeBSD. The main answer is "turn this off if you are chrooted". > If this is what it takes to get Coda, I for one won't use it, but I > can probably create and commit a kernel option that give the access > methods so that others can. One problem here is that the per process root FS being equal to NULL is considered to be a non-chrooted environment; actually, the compare should be done against the known real root vp, to see if it's the same, and the known real root vp should be set: the value of NULL should not be used to determine "chrootness" (ie: it breaks for relative paths). This is one of my patches to namei, though it needs a patch to init's startup, as well, to inherit the original root vp into the proc struct. If you don't use chroot in combination with this, it's not a problem; if you do, well, it's a security bug in FreeBSD's namei() implementation. > It will not be part of FreeBSD in the default configuration, at least > not if I have any say in the matter. (Sorry to be so brutal, but it > really kill a lot of security assumptions.) Technically, this could use the NFS server locking fcntl() which is used to convert NFS file handles into an open fd. I like this option better than leaving it out, better than the namespace incursion, but less than the POSIX namespace escape (I can prove a fixed namei() is topologically equivalent to a vouchsafe, if necessary, and if you are willing to withstand topology , group theory, and Clifford algebra's; most people just take my word for it... ;-)). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802122004.NAA20960>