lean cloud push overwrites read-only shared library files

从 lean cloud push 流程开始，跟踪链接的库文件如何到达 /files/update 或 /files/create。检查 /projects/read 如何暴露协作者访问权限，然后复现只读库场景。完成的标准是：只读库文件会被跳过或拒绝，且不会覆盖云端更改，同时相关的 push 行为由测试覆盖。

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