lean cloud push overwrites read-only shared library files

lean cloud push overwrites read-only shared library files

Summary

When a project references a shared library for which the pushing user has read-only (collaborator) access, lean cloud push still uploads the locally cached library files via /files/update, effectively overwriting whatever the library owner has since changed on the cloud. The access control on the library project is not consulted before the push.

Reproduction steps

1. Create a library project and share it across an organisation as read-only (i.e. other members are added as read-only collaborators, not owners).
2. A read-only collaborator runs lean cloud pull on a project that references this library → library files are downloaded locally.
3. The library owner pushes new changes to the library in the cloud.
4. The read-only collaborator runs lean cloud push on the project (not on the library directly).
5. Observed: the cloud library files are reverted to the version the read-only collaborator had locally from step 2.
6. Expected: lean cloud push should skip pushing files for libraries where the current user has read-only access (or the cloud API should reject the write with an appropriate error).

Root cause (hypothesis)

lean cloud push iterates over all local project files, including the contents of every linked library directory, and calls /files/update or /files/create for each. It does not check the authenticated user's role on the library project before pushing library files. The result is that a collaborator who cannot directly write to a library via the web IDE or via lean cloud push <library> can inadvertently overwrite it by pushing the parent project.

Suggested fix

Before pushing library files, retrieve the calling user's access level on each library project (e.g. via /projects/read for the library's project id and checking the collaborator role / access flag). Skip — or error — on any library where the user is not an owner or write collaborator.

A complementary server-side guard on /files/update to enforce the library project's collaborator permissions would provide defence-in-depth regardless of the client.

References

• Intercom conversation id: 215475353035232
• Related lean-cli open issue: #579 (Improve semantics of library organisation — may overlap)
• LEAN CLI docs: https://www.quantconnect.com/docs/v2/lean-cli/projects/libraries/project-libraries

Start at the lean cloud push flow and trace how linked library files reach /files/update or /files/create. Check how /projects/read exposes collaborator access, then reproduce the read-only library scenario. Done means read-only library files are skipped or rejected without overwriting cloud changes, with the relevant push behavior covered by tests.