-
Notifications
You must be signed in to change notification settings - Fork 379
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
Consider clipboard diode restrictions to selectively allow cross-container clipboard sync #379
Comments
Thank you for the suggestions! However, a separate tool for this would be quite nice. Clipboard handling is not part of the container area but entirely handled by the X servers. x11docker runs additional X servers. It uses So your request is about clipboard handling of multiple X servers (with all the possible features you've mentioned). It seems there is no tool in the wild that provides this, I've already searched a lot previously. If you find such a tool or even develop one yourself, I would appreciate it very much! |
I have added some optional arguments to option
With This is not as advanced as you have suggested, but I assume it covers most use cases while still being easy to handle. |
Given the use case of running multiple
x11docker
containers simultaneously, I'll suggest the possibility of restricting the flow of information between these containers by leveraging a declarative approach.Let's assume for now that running
x11docker
containers are tagged with a property, likerole:work
,role:shopping
,role:source
(a source container with passwords for example) orrole:sink
(for archiving).With the principle of least privilege to hand, a user may identify a frequent need to send clipboard contents from a certain class of containers to another, but not necessarily in the reverse direction. I mention the tag/property system because it would make it easier to spin up a new container that inherits the same permissions with respect to clipboard sharing, without requiring the overhead of redoing that configuration for a very similar container. The user could find their own way of binding a key sequence to quickly configure permissions, and so if
x11docker
provides a command line interface for this configuration, this may be sufficient. That is, a full-fledged UI wouldn't be needed for the base functionality. Directives can be allowed to specify the flow of information, whether that's a permenent flow or temporary; and then other directives can be allowed to facilitate the actual copy and paste commands (although the latter could be triggered by events such as clipboard read/write).Suppose by default all sharing is blocked. But a user may want to enable sharing from
role:shopping
torole:sink
so that they can archive the URL from a shopping container freely. The one way nature of this declaration would preventrole:shopping
from seeing any other clipboard shares unless explicitly permitted. Another kind of share might be time-bound: say for 30 seconds, clipboard contents would be available, but after that point, all clipboard contents in all applicable containers becomes cleared to the null string, for all "selection" mechanisms (usingxclip
terminology). That way, a password can temporarily be propagated from a password-manager container (say that it's inrole:source
) to a container that's using it (in this case,role:shopping
) and then this flow is allowed temporarily while others are blocked by default.The automatic clearing of contents when the contents have been successfully shared (or after a time bound) would increase security, especially since the user may not always be inclined to clear contents in multiple containers manually, and for all selection mechanisms. I'm not sure if it's possible to detect when the clipboard contents were consumed (by a "paste" command) but if so, this could make the use of the data one-time.
In considering this, other functionality can also be evaluated for inclusion. There might be other projects aimed at clipboard sync, both local and remote, and thus a comparable interface used in multiple cases. Also, a very lightweight layer of encryption could be used to grant even greater security and prepare for a future-scoped possibility of sharing information across host boundaries. Say for example based on faster elliptic curve primitives for speed. But much like GnuPG allows for multiple recipients, a clipboard content that is allowed to be "read" by more than one tag can encrypt the ephemeral symmetric key for various asymmetric key recipients. Still, the data can be kept in RAM only for good measure (although if the host uses unencrypted swap this justifies the importance of encrypting the data for safety).
Any time I copy and paste, that particular need to do so drops after a minute when the paste is complete. And so a periodic process that automatically clears contents of all clipboard selections in all containers would itself be an important enhancement, because this focuses on the minimal requirements of that copy/paste only. However I also suggest some advantages of allowing clipboard sync to be a declared as an opt-in property. I also may want to copy from a certain container's clipboard into another container's clipboard but in such a way that the host itself never needs to see those contents. Stepping back, perhaps a subsystem of copy/paste, if implemented could allow for other enhancements, like transparent interoperability between various environments.
The text was updated successfully, but these errors were encountered: