Set OneDrive permission scopes during configuration to enable Files.ReadWrite.AppFolder

[ToeKneeFan]

The associated forum post URL from https://forum.rclone.org

https://forum.rclone.org/t/set-onedrive-permission-scopes-during-configuration/27506

What is your current rclone version (output from rclone version)?

rclone v1.56.2
- os/version: ubuntu 20.04 (64 bit)
- os/kernel: 5.4.0-90-generic (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.16.8
- go/linking: static
- go/tags: none

What problem are you are trying to solve?

At the moment, it is possible to set the permission scope for Google Drive access during configuration. However, it appears this has not yet been implemented for OneDrive. Would it be possible to add scope configuration for OneDrive as well?

This request is analogous to this request except for OneDrive instead of Google Drive. This is useful for contexts where one would like to leverage a large capacity of OneDrive storage for an application or research purpose without exposing the account's entire drive, which might contain sensitive information. This could be implemented by granting only app-specific storage in OneDrive (Files.ReadWrite.AppFolder). Although I realize the authentication token lives client-side, I'd like to minimize exposure to potential exfiltration from the drive outside of the scope of the rclone use case in the event that the device is compromised.

How do you think rclone should be changed to solve that?

It could be changed to include the option to select the permission scope for OneDrive access during configuration.

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

[scyto]

agree 100%, i found a project that is using rclone in it (i was unaware of rclone until yesterday) - the scopes the app asks for for onedrive make it untenable for production use IMHO (and a security and privacy nightmare). It has access to read and write not just all my files but every file anyone has ever shared with me.

Agree 100% that it should default to much smaller scope set and ideally just Files.ReadWrite.AppFolder

@ToeKneeFan did you ever 'take a crack at it' :-)

[ncw]

I think this was done in 50c2e37 - you can specify which scopes you want. This was released in v1.59.0.

I'm going to close this as I think it is done :-)

[scyto]

thanks, i didn't see Files.ReadWrite.AppFolder mentioned in the commit changes, but assume the permissions scopes listed in the commit are just examples?

[ToeKneeFan]

Sorry for the delay; I took a crack at it some time ago, but getting Files.ReadWrite.AppFolder required more work, and I had to put it off for some other commitments. From what I can tell, 50c2e37 is not yet sufficient for this permission.

[ncw]

thanks, i didn't see Files.ReadWrite.AppFolder mentioned in the commit changes, but assume the permissions scopes listed in the commit are just examples?

Yes, you can put your own set of permissions in.

Sorry for the delay; I took a crack at it a some time ago, but getting Files.ReadWrite.AppFolder required more work, and I had to put it off for some other commitments. From what I can tell, 50c2e37 is not yet sufficient for this permission.

You can certainly add the permission, but there may be other things to do - do you know what @ToeKneeFan ? I'd guess it revolves around choosing the correct root directory which shouldn't be very complicated.

[ToeKneeFan]

Yes, the root has to be changed to the special AppFolder root (/drive/special/approot), though I think other changes may be needed as well.

[ToeKneeFan]

Ah, the reason why simply changing the root is not sufficient is because much of the logic in onedrive.go builds the paths systematically to use item IDs (i.e., https://{Endpoint}/drives/{driveID}/items/{itemID}/{route}), but API requests with Files.ReadWrite.AppFolder do not accept item IDs at all (relevant OneDrive API documentation). For example, uploading a file with AppFolder permissions would be PUT /drive/special/approot:/{parent-path}/{name}:/content. Other interfaces (such as this one) have run into issues for similar reasons.

[ncw]

Hmm, that looks complicated @ToeKneeFan !

Shall I re-open this issue or do you want to make a new one specifically about using Onedrive with AppFolder?

[ToeKneeFan]

Either way works! Would it be okay to re-open? Although titularly the issue was about adding scopes, the primary purpose was for adding Files.ReadWrite.AppFolder.

[ncw]

Ok I'll reopen and rename.

Do you have an in progress PR?

[Donovan22]

I am not very familiar with go, but I found this project written in it that is already using Onedrive app folders for backups and I thought I should drop it here for reference:
https://github.com/virtualzone/onedrive-uploader
Hopefully it helps!

[ToeKneeFan]

Ok I'll reopen and rename.

Do you have an in progress PR?

That sounds great. I do indeed, though I have not committed changes to the public repository. I will see if I can work out the changes needed.

[ncw]

Let me know if you need help.

[Donovan22]

I hope you're all doing well. I wanted to ask if there has been any progress on implementing this feature. It would be incredibly beneficial for my use case, as it would allow me to leverage OneDrive storage without exposing my account's entire drive.
Any updates would be highly appreciated.
Thank you for the progress so far.

[crazyuploader]

I hope you're all doing well. I wanted to ask if there has been any progress on implementing this feature. It would be incredibly beneficial for my use case, as it would allow me to leverage OneDrive storage without exposing my account's entire drive. Any updates would be highly appreciated. Thank you for the progress so far.

+1, would love to know the progress about it as well, can't expose all my personal files!

[pp244]

+1, this addresses an important usecase where I do not want to expose the entire onedrive to a not-so-much-trusted machine that needs to do automated uploads.