On Mon, Jul 17, 2006 at 03:07:51AM +0100, Neil Mitchell wrote: > Hi Brian, > > >I kind of expect that a Haskell library for file paths will use the > > type system to ensure some useful properties about the paths. > > I am specificially concentrating on type FilePath = String, because > that is how it is defined by Haskell 98. And consequently that's how > it works with readFile/writeFile/appendFile etc. > > Perhaps a far better solution to this would not be to hack these kind > of guarantees in at the filepath level, but have a restricted IO monad > that only lets you perform operations inside certain directories, or > only lets you read/write files. I know that both House and Halfs use > these techniques. Without too much effort Yhc (for example) could be > modified to perform restricted IO operations (only on certain > directories etc). > > You seem to want to distinguish between relative, relative down only > and absolute paths. By putting this in the filepath, and having > different types for each, you pretty much guarantee that all standard > functions will operate on all 3 types of path, so you don't gain any > security that way, since mistakes will still slip through. How about > adding something like "restrictFilePaths :: FilePath -> IO ()" which > will restrict the area that can be played with to that beneath the > given FilePath?
Darcs also does something similar (typeclasses for control of IO actions), and this is certainly the way to go. However, I also agree that type distinctions between paths would be nice. My preference has long been that the "FilePath" should be a class rather than a type. Then one could have single IO functions that accept restricted and unrestricted file paths, and other ones that accept only restricted file paths, so you could get compile-time checking that your "safe" chroot monad won't die at runtime. -- David Roundy _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe