[Haskell-cafe] RE: ANN: System.FilePath 0.9

[David Roundy]

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