Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix notebook trust in RTC #12756

Closed
wants to merge 1 commit into from

Conversation

davidbrochart
Copy link
Contributor

References

None.

Code changes

Propagate cell trust to/from shared model.

User-facing changes

The notebook trust mechanism now works in RTC.

Backwards-incompatible changes

None.

@jupyterlab-probot
Copy link

Thanks for making a pull request to jupyterlab!
To try out this branch on binder, follow this link: Binder

@davidbrochart
Copy link
Contributor Author

Trigger CI.

@davidbrochart davidbrochart reopened this Jun 30, 2022
const codeCell = this.sharedModel as models.YCodeCell;
const metadata = codeCell.getMetadata();
metadata.trusted = true;
codeCell.setMetadata(metadata);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it mean that if other users execute one cell, this cell on my notebook is trusted automatically?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I would say that if they can execute a cell it means they are trusted users. What do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The feedback I get from my PR (#11494 (comment)) is that in some contexts, trusting automatically, especially for cells containing JS code, can make users exposed to intended attacks

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that user roles can be part of the picture here, for instance giving a user the right to execute cells implicitly means that this user is trusted.
But since we don't have roles yet, maybe your work in #11494 could be extended to all outputs, not only widgets?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, since users have the right to execute cells, they are trusted for their activites on the server-side. My PR prevents malicious activities on the frontend side, which mostly relates to the HTML/JS rendering. So I don't think we need to extend this to the text/plain output.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But outputs can execute JavaScript too, if they are of type text/html. This is what the trust mechanism protects from. So I think your PR can be very relevant in this case too.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For now, I only check the application/* type, but indeed I also need to take a look at the text/html type.

@fcollonval fcollonval added this to the 4.0.0 milestone Jul 7, 2022
@fcollonval
Copy link
Member

We should discuss this at a JupyterLab call.

There is something wrong to use the cell metadata to store the trust status (actually there is a protection to clean that key in nbformat when reading or writing a notebook).

Although I agree on the statement, if the user has execution rights, everybody should trust him. But using the metadata implies modifying the data will change the trust for everybody; this may not be wanted if the expected roles are read, read/write, read/write/execute.

@davidbrochart
Copy link
Contributor Author

There is something wrong to use the cell metadata to store the trust status (actually there is a protection to clean that key in nbformat when reading or writing a notebook).

In this PR I only apply the current trust mechanism, but it's true that it works by passing a trust flag in the cells' metadata transiently between the front-end and the back-end (this information is not saved in the notebook format).
Whether or not to keep this mechanism is out of the scope of this PR.

@ellisonbg
Copy link
Contributor

I think this makes sense. The alternative is for cell-level trust to not be shared and for each individual users to need to trust (run) each cell. That seems redundant and inconsistent with the level of mutual trust that collaborators need to have in each other to do real-time collaboration where everyone can run code.

@ellisonbg
Copy link
Contributor

@davidbrochart can you rebase?

Others, any more comments on this?

@davidbrochart
Copy link
Contributor Author

@davidbrochart can you rebase?

Actually my changes don't apply any more to the master branch, for instance _updateModelDBMetadata doesn't exist any more.
If the goal is to have this change in JupyterLab v3, maybe I should open this PR against the 3.6.x branch (when it is created)? And maybe open a new PR for master?

@SylvainCorlay
Copy link
Member

I think this should be merged in 4.0 first.

This was referenced Oct 19, 2022
@davidbrochart
Copy link
Contributor Author

I opened #13274 (same as this PR but on 3.6.x) and #13273 (equivalent to this PR but on master).
Closing.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 20, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants