Rclone alias-type remotes

Get Help
1

Hello,
I’m experimenting with enabling rclone remotes as a way of allowing users to access a local S3-style storage system from the file browser. However, there are permissions issues with allowing users to list all buckets at the top level of the filesystem, so I want to be able to instruct them to set an alias directly into their project’s bucket, i.e. an rclone alias-type remote that points “foo:” to “local-s3:foo-data/”
When testing this, I see the following message:
Remotes of type alias are not allowed due to ALLOWLIST_PATH
What should I add to OOD_ALLOWLIST_PATH to include rclone remotes?
Thanks in advance,
Sophia

2

I could comment on this as I’m the person that implemented that restriction.
Right now, there is no way to enable those. Using Rclone alias and local remotes allows bypassing the configured OOD_ALLOWLIST_PATH, which is why I chose to simply disable those. So this is something that would need to be implemented, either by allowing alias and accepting that OOD_ALLOWLIST_PATH may be bypassed if someone is determined, or actually validating the path.
See the TODO I wrote here: ondemand/apps/dashboard/app/controllers/files_controller.rb at ab2505a0e5b5f096408ea040a85f03a38cc8e9b3 · OSC/ondemand · GitHub

An alternative could be to use the Files menu shortcuts for this if you are able to determine the bucket names and remotes programmatically and they are guaranteed to exist.
This does not seem to be documented in the link above, but you would do something like: FavoritePath.new('/foo-data', title: 'Local S3 (foo-data)', filesystem: 'local-s3')

3

Thanks, this is very helpful! I think I will be able to figure out a workaround with this info.

Out of curiosity, if/when path validation is implemented, how would the “pattern” in OOD_ALLOWLIST_PATH be represented? Would it include the remote name or endpoint? Or would it only validate the bucket path on the remote server? It seems to present a bit of a challenge with users being able to configure their own remotes (and possibly do so incorrectly).

4

This is not something that is on my TODO list right now.
I’m not sure if validating based on the remote name makes sense as you mentioned, since those are under user control unless you manage the configuration for them and don’t allow them to write to it.

In our case, we’re only interested in validating the local paths.
So, what I had in mind there was to evaluate what the alias remote is an alias of, until a non-alias remote is reached. If it is an alias of a local remote, the path would be validated according to OOD_ALLOWLIST_PATH.

So e.g. if OOD_ALLOWLIST_PATH contains /home:/scratch and these remotes are configured:

  • localalias is an alias for local
  • s3alias is an alias for s3:/foo
  • homealias is an alias for local:/home
  • etcalias is an alias for local:/etc
  • aliasalias is an alias for localalias

It could work something like this:

  • local:/home/myuser → OK, /home in allowlist
  • local:/etc/passwd → not OK, /etc not in allowlist
  • localalias:/home/myuser → local:/home/myuser (evaluate alias) → OK, /home in allowlist
  • homealias:/myuser → local:/home/myuser → OK, /home in allowlist
  • etcalias:/myuser → local:/etc/myuser → Not OK, /etc is not in allowlist
  • s3alias:/something → s3:/foo/something → OK, allowlist is not used for s3 remotes
  • aliasalias:/etc/passwd → localalias:/etc/passwd → local:/etc/passwd → not OK, /etc is not in allowlist