Split FilePath constructor to guarantee constructor with AmbientAuth

[rhagenson]

Please let me know what y'all think.

I do not believe I have overlooked any immediate problems with a second constructor for FilePath.

Running simple statistics within the stdlib showed a slight bias towards building using AmbientAuth so I kept that as the half of the union used within create.

Rendered

[ergl]

I think this could be mitigated if we added a new *Auth capability that only works for creating files, similar to what we do in the net package (UPDSocketAuth, TCPListenerAuth, etc.)

Let's say I create a library that only needs access to the filesystem, but not networking. It's true that the user could supply a crafted FilePath instance, but maybe they don't care about specifying the path, or capabilities of that path: they only care about authorizing the library to modify the filesystem.

This new Auth class can be implemented in terms of FilePath: FilePath.create(AmbientAuth, "/", recover val FileCaps .> all() end)

[rhagenson]

I do not understand what you mean. We have a capability only for creating files FileCreate. Using FilePath.create(AmbientAuth, "/", recover val FileCaps .> all() end) would mean the ability to create any FilePath with any capabilities via the suggested FilePath.from(...) constructor so I do not see what that is fixing.

[ergl]

Sorry, I might have explained myself badly.

What I mean (and what you also put in the RFC), is that by taking AmbientAuth, FilePath.create incentivizes library authors that need to access the filesystem to ask the user for a very coarse-grained capability.

Imagine you're a library author: your library is only interested in using the "files" package, but you don't necessarily want to ask the user to pass your library a FilePath class (maybe you don't want the user to think about paths). Your other option is to ask the user for AmbientAuth, and you will use this auth inside your library to create FilePath classes as you need them.

However, AmbientAuth allows you do to much more than creating FilePaths: since it is the root Auth, you can use it to create other auths like TCPListenerAuth and open network connections behind the user's back.

My suggestion here is to create a new *Auth primitive, for example FileAuth, and use that as a parameter for FilePath.create, instead of using AmbientAuth. That way, we use an auth that is only used for filesystem access, much like we do in the net package already.

[rhagenson]

That makes a lot more sense now. Thank you for clarifying.

[rhagenson]

I am in favor of this, but exactly how we want it to be implemented is a topic of discussion. Integrating it with this RFC I see the same split occurring so we have:

new val create(
    base: FileAuth,
    path': String,
    caps': FileCaps val = recover val FileCaps .> all() end)
    ?
  => ...

and

  new val from(
    base: FilePath,
    path': String,
    caps': FileCaps val = recover val FileCaps .> all() end)
    ?
  => ...

where FileAuth can be created via AmbientAuth via

primitive FileAuth
  new create(from: AmbientAuth) =>
    None

This FileAuth would then be used to produce any lower auths.

---

My primary concern with this is that it seems dangerously close to duplicating the purpose of FileCaps. I want to push this forward as I prefer the pattern of a package having its own dedicated root auth -- when the alternative is passing AmbientAuth around without much regard for how that would then allow use within any yet-written package. By creating our own root auth we prevent this before it can become a problem and anyone with AmbientAuth is only a single FileAuth(AmbientAuth) away from the solution.

[SeanTAllen]

I like the idea of having a FileAuth. I think its reasonable and matches up with how the net package works.

It's a pretty easy thing for a user to fix. I'd be in favor of expanding this to include that change.

I'm also ok with it staying with AmbientAuth for now.

I don't think that FileAuth is too close to FileCaps. FileAuth is "you can do file stuff", file caps is specific file operations you can do.

[jemc]

I'm on the same page as Sean.

I particularly don't think there is significant duplication, because in the past I have advocated for the net package to get something akin to FileCaps (e.g. I'll allow you to open a single listener within this port range, but you can do nothing else with networking apart from that).

So like Sean, I don't see any troubling overlap between "you can do any file stuff" and "you can do this specific subset of file stuff".

[rhagenson]

Got it. I will expand the RFC this evening to include a new FileAuth package-level root.

[SeanTAllen]

It should be without error to constructor a FilePath when AmbientAuth is available.

Definitely a typo in there somewhere.

[rhagenson]

I would say so. Not sure how I did that.

[SeanTAllen]

This looks good to me. I made a comment on the first sentence that has a typo or two and is currently not clear.

[jemc]

I can't think of sub-authorities that might be needed that couldn't be accomplished with just FilePath.

If we think of sub-authorities in the future, we should be able to add them without a breaking change.

So I'm not worried about this as an unresolved question at this time.

[SeanTAllen]

Accepted!