Good comments, David.

David Green wrote:
So the set of default standard dirs would just be a hash of IO objects: $IO::DOI{home}, $IO::DOI{docs}, etc. Actually, different OS's would provide different sets of standard named dirs, and you should be able to import them:

# Assume I'm running on a Mac, so $IO::DOI::MacOSX is automatically loaded use IO::DOI <Home Music Downloads>; # names that ::MacOSX makes available

    say $Home;         # /Users/david
    say $Music;        # /Users/david/Music
    say $Downloads;    # /Users/david/Junk drawer

Similarly, I think it very reasonable that for OS's like Windows where it is commonplace for paths to start with a particular disk volume, then $IO::DOI::Windows would automatically load a DOI for each mounted disk; eg that $C or $E etc would be pre-defined.

There will be a few names that should be standard as much as possible across OS's, e.g. "Home" even though on a Mac the dir is actually called "Users". "Trash" might be another one (which will be undef if the OS doesn't handle it).

"Trash" wouldn't be so simple since there are multiple ".trash" directories; for starters, at least one for each logical disk volume, and also one inside each home folder under Users. If we had a "Trash", it would have to pick one of those. Anyway, this is a minor issue that doesn't need to be worried about now.

This doesn't address the security side of things; dir objects might have a flag you can set so that it will warn you (perhaps fatally) if you try to use $dir.parent or "$dir/..", etc., but you could always get to an outside dir some other way. I think a more explicit way to set a chroot is better, such as:

    $IO::Root = $*CWD;
    $IO::Root = $Home;
    temp $IO::Root = $IO::DOI{Docs};

I would say that by design a "$dir/.." or $dir.parent should simply be impossible; if someone tried to write that, they would get a subdir named "parent" or "..", or a fatal warning if that isn't possible.

Similarly, if a Perl thread does not see any DOI at all, then they effectively are denied access to the filesystem period.

Hm, undef $IO::Root?

Of course, that still doesn't cover everything your suggestion does, because your way allows for multiple roots. But you also weren't suggesting a specific syntax, and I'm leaning to something like my example above. Perhaps along the lines of:

    $IO::Root{"file"} = "/";         # default root (assumes "file://")
    $IO::Root{"http"} = "http://";;   # means any website
    $IO::Root{"ftp"} =  "ftp://";;    # etc.

What I had in mind was that every canonical DOI just lives as a member of a single hash, and deleting the hash key is how you remove one. If you have a separate variable for a single one then any use of it would be semantically equivalent to substituting a hash access in its place, and the variable would be undefined if the corresponding DOI doesn't exist, like a Perl 5 weakref when its target is garbage-collected.

Every time you use IO::Some_protocol_name, it would set a default $IO::Root{protocol-name}. But there's nothing special about the names; you can add or change $IO::Root as you wish.

    $IO::Root{"file"} = "/foo";
    $IO::Root{"more files"} = "/bar";
    # Now can access only files that come under /foo or /bar

    $IO::Root<$_>.delete for «file "more files"»;
    # Now there are no more file:// roots, cannot access any files

    $IO::Root<http> = "http://localhost/~david/";;
    # Now can access only URLs from my section of the local website

Hm, having just written that, it obviously should be the case that $IO::Root<file> should be a hash with all the available "file:" roots, i.e. $IO::Root is a hash-of-hashes where the keys are {protocol-name}{arbitrary-name}. And the default arbitrary-name might just be "default".

-- Darren Duncan

Reply via email to