rclone / rclone

"rsync for cloud storage" - Google Drive, S3, Dropbox, Backblaze B2, One Drive, Swift, Hubic, Wasabi, Google Cloud Storage, Azure Blob, Azure Files, Yandex Files
https://rclone.org
MIT License
47.26k stars 4.23k forks source link

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

Open ToeKneeFan opened 3 years ago

ToeKneeFan commented 3 years ago

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

scyto commented 2 years ago

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 commented 2 years ago

I think this was done in 50c2e37aac746466ed4159ada1d40316ea302481 - 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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

Ok I'll reopen and rename.

Do you have an in progress PR?

Donovan22 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

Let me know if you need help.

Donovan22 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

+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.

mvevitsis commented 5 months ago

Is this still not implemented?

crazyuploader commented 5 months ago

Is this still not implemented?

Guess not

ToeKneeFan commented 5 months ago

Sorry, I haven't had much time to get this to work. This would require more sophisticated treatment than initially proposed, as files are addressed completely differently with the AppFolder permissions API. If anyone would like to try, they are of course welcome.