Date: Tue, 13 Jun 2000 12:55:11 -0400 From: Dan Moschuk <dan@FreeBSD.ORG> To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: David Gilbert <dgilbert@velocet.ca>, freebsd-current@FreeBSD.ORG Subject: Re: (thoughts on) the mktemp() patch. Message-ID: <20000613125511.C834@spirit.jaded.net> In-Reply-To: <394537FE.9AD506CD@newsguy.com>; from dcs@newsguy.com on Tue, Jun 13, 2000 at 04:20:30AM %2B0900 References: <14660.2642.194412.404753@trooper.velocet.net> <394537FE.9AD506CD@newsguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
| > | > Maybe the soltion is to think out of the box. Maybe temporary | > filestore should be a more official OS service. Race conditions would | > be far less common if the OS itself was managing the namespace. | > | > You might even expand the capability somewhat. Provide process local, | > uid local and global namespaces. You'd even gain the ability to | > specify the limits on temporary filestore. | | We have an out of the box solution. But there are other software out | there in the world that happens to use mktemp() and we have no control | of. So we are trying to improve mktemp(). I've avoided this conversation, but what would everyone think of a tmpfs type of solution with a security minded design? I took a brief look at phk's md driver, and it could be quite easily molded to do what I want to do. Things like a sysctl option to disallow symlinks in a tmpfs mounted directory I'm sure would make a few people happy. The downfall, for being memory backed, is it's wiped on a reboot (some people, however, consider this to be A Good Thing). -- Dan Moschuk (TFreak!dan@freebsd.org) "Don't get even -- get odd!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000613125511.C834>