Here is an example of what a compositor can implement:

2018-10-16 17:47:25     jadahl  for the client to actually get the content, there needs (well, if the compositor demands this) to be an explicit user interaction (key press, button click etc)

Full #wayland log:

2018-10-16 14:47:18     atralheaven     Hi, I want to know how does wayland secure the clipboard contents? for example, if I copy a password from my password manager, can other 
apps have access to it before I paste it in any of them?
2018-10-16 14:55:04     jadahl  atralheaven: its solved by requiring you, the user, interacting with the surface that should get the content. for a application to have the abili
ty to paste, it currently needs to have keyboard focus. we might drop that requirement, and replace it with something more generic such as "being active", but then also require 
a paste in response to an input event (such as touch-down)
2018-10-16 14:55:39     jadahl  atralheaven: any arbitrary client, e.g. in the background, or one you didn't focus or interact with, will not be told about the availability of a
ny clipboard content at all
2018-10-16 15:00:48     atralheaven     I'm curious, when I copy somthing, I want to paste it somewhere, why should a proccess have  access to the clipboard contents at all? why
 not making the paste action the only way for applications to access to clipboard contents?
2018-10-16 15:03:00     jadahl  atralheaven: the compositor is the process that'll be aware that client A has "copied" something. in the normal case (given how the compositor im
plements it), no content will be transferred until the "paste" action is done. the "paste" action is done by the target (lets say client B). the content is then transferred dire
ctly from client A to client B
2018-10-16 15:03:49     dominikh        I think he's suggesting that the compositor sends the clipboard to a client, not that a client be able to request the clipboard content; 
focussed or not.
2018-10-16 15:04:21     dominikh        naturally that'd require the compositor to know what should trigger a paste in the first place
2018-10-16 15:04:22     jadahl  the compositor doesn't send any clipboard, it just notifies clients about it
2018-10-16 15:04:44     jadahl  ..normally... the compositor can pretend to be a client and "paste", of course
2018-10-16 15:08:20     jadahl  atralheaven: something like this: [clientA->compositor] I have content with "mimetype" available. [user] Focus clientB. [compositor->clientB] som
e one has made available content with "mimetype". [clientB->compositor]: I want it. [compositor->clientA]: Someone wants content. here's an file descriptor, send it there. [comp
ositor->clientB]: the content will arrive here *hands over file descriptor*
2018-10-16 15:09:24     jadahl  (i might be wrong with who creates the fd, but it works like that more or less)
2018-10-16 15:10:09     dominikh        (note that I wasn't trying to explain the status quo, but atralheaven's idea of what it should be like) – the commonly voiced concern is 
that when focus follows mouse, many unintended clients get to access the clipboard.
2018-10-16 15:10:19     dominikh        hence the "they shouldn't be able to request it" sentiment
2018-10-16 15:11:11     jadahl  dominikh: IIRC that can be avoided with requiring a real input event serial, not just a focus event serial
2018-10-16 15:11:30     jadahl  i.e. a button press, touch-down, key-press etc, on the focused window
2018-10-16 15:11:42     dominikh        makes sense
2018-10-16 15:26:04     pq      did we not require a real input event serial already?
2018-10-16 15:34:54     linkmauve       At least Weston does.
2018-10-16 15:39:41     jadahl  pq: not sure its anywhere in the spec at least
2018-10-16 15:40:22     pq      if Weston does, then it must be in the protocol interface as well
2018-10-16 15:43:24     jadahl  i might be looking the wrong places but I can't see it being spelled out
2018-10-16 15:49:25     pq      so is there an undocumented argument in the interface?
2018-10-16 15:49:39     pq      I suppose we have that a lot for the serials
2018-10-16 15:51:11     jadahl  the serial of "accept" is undocumented, yes
2018-10-16 15:51:32     jadahl  but the serial is really more about avoiding the race condition, than requiring interaction
2018-10-16 15:52:18     pq      hard to say when it
2018-10-16 15:52:23     pq      's not documented
2018-10-16 15:53:18     jadahl  some fancy xml scripting might help. e.g. for each argument in request -> grep argument request.description
2018-10-16 15:54:29     pq      I suppose we'll need an interface version bump to start using the serial for strict access control
2018-10-16 15:55:01     pq      I've seen things like using the wl_surface.frame request's wl_callback.done's argument passed in as an input serial...
2018-10-16 15:55:27     pq      or wait, maybe it was even wl_display.sync's
2018-10-16 15:55:41     jadahl  just to check that there was some interaction doesn't need a serial
2018-10-16 15:56:05     jadahl  the client can lie about a serial as well
2018-10-16 15:56:38     pq      yeah, a client can lie about serial, which is why compositors should check for strict equality
2018-10-16 15:57:11     jadahl  just to check that there was interaction it can just check its own serials and ignore the client one
2018-10-16 15:57:28     pq      that's a good point
2018-10-16 15:57:46     jadahl  i.e. surface.focus_serial < surface.key_serial etc
2018-10-16 15:59:12     pq      was there a way to associate a surface?
2018-10-16 15:59:22     jadahl  associate a surface with?
2018-10-16 15:59:35     pq      a paste attempt, or accept request
2018-10-16 16:00:06     jadahl  a offer is only sent to a client which has keyboard focus, and I guess one can use that surface
2018-10-16 16:00:23     jadahl  a selection offer
2018-10-16 16:00:31     jadahl  dnd is more direct, with enter/leave on a surface
2018-10-16 16:01:14     pq      right, and there shouldn't be any "getter" for clipboard contents either, so wonder what that question was about
2018-10-16 16:01:32     jadahl  maybe just about how it works in general
2018-10-16 17:29:09     atralheaven     the thing that I was worried about was a problem which I first saw in android, it seems that its name is pastejacking, I talking with a friend about it, and he said wayland have considered solving this problem.
2018-10-16 17:30:08     atralheaven     do other processes have access to clipboard contents, or they just know something exists in the clipboard, without knowing what it is?
2018-10-16 17:30:28     atralheaven     and by other processes I mean the ones which are allowed, like the focused ones
2018-10-16 17:36:02     jadahl  atralheaven: other clients/process doesn't know anything about the clipboard without the compositor telling them, and it only does that when a user actively focused the clients surface
2018-10-16 17:40:08     atralheaven     jadahl: so with focusing, it can know the contents of the clipboard? can I limit this only to the paste action? I mean before pasting, client knows nothing about the clipboard content, and only it knows the content when the pasting have actually occurred.
2018-10-16 17:41:51     atralheaven     and why shouldn't this be the default mode? why does a client need to know the clipoard content before user pastes it?
2018-10-16 17:43:18     dominikh        because it is the client that knows whether you're pasting or not? the client is handling whatever the means of pasting are (menu items, key combinations, …)
2018-10-16 17:43:58     dominikh        it doesn't know it "before pasting". it is who says "we're pasting"
2018-10-16 17:46:18     jadahl  atralheaven: focusing, it'll know *about* the clipboard, not the content
2018-10-16 17:47:25     jadahl  for the client to actually get the content, there needs (well, if the compositor demands this) to be an explicit user interaction (key press, button click etc)
2018-10-16 17:48:22     jadahl  dominikh: the client might have its "Paste" button clicked, when that happens it'll ask the compositor to establish a data transfer file descriptor. the compositor can for example make sure it did so in response to a button click
2018-10-16 18:11:44     atralheaven     perfect! how does x11 currenly behave about clipboard?
2018-10-16 18:12:07     otaylor atralheaven: any application can snoop on the clipboard at any time
2018-10-16 18:13:23     otaylor (Note only that, depending on toolkit details, it's often true that any app can snoop on *text selected by the user* at any time. But then again, any app can also snoop on screen contents at any time...)
2018-10-16 18:13:26     atralheaven     I think it's time to switch. which DEs can work with wayland now?
2018-10-16 18:13:59     jadahl  atralheaven: to really make anything secure, using wayland is not enough. you need sandboxing and what not as well
2018-10-16 18:15:40     jadahl  atralheaven: because while wayland isolates clients from each other, clients are still free to poke around in $HOME etc as much as they want
2018-10-16 18:23:29     atralheaven     sure, it's not my pnly reason for switching to wayland, but I liked to know how does wayland do about this. I want try wayland and stay there if there was no problem because it works in a much more simpler way than x11, which apparently it has become a mess now.
2018-10-16 18:26:43     ajax    that's not fair. x11's always been a mess.
2018-10-16 18:27:54     ramcq   haha
2018-10-16 20:00:30     -->     lsd__ (~lsd@cpc140238-melt3-2-0-cust717.12-1.cable.virginm.net) has joined #wayland
2018-10-16 20:01:59     <--     random_yanek (~random_ya@host-89-230-164-27.dynamic.mm.pl) has quit (Quit: random_yanek)
2018-10-16 20:09:32     <--     luke-jr (~luke-jr@unaffiliated/luke-jr) has quit (Excess Flood)
2018-10-16 20:09:47     emersion        jadahl: note that the serial is only required for wl_data_offer::accept
2018-10-16 20:09:50     -->     luke-jr (~luke-jr@unaffiliated/luke-jr) has joined #wayland
2018-10-16 20:09:54     emersion        wl_data_offer::receive doesn't need it
2018-10-16 20:10:18     emersion        and then you see clients like this which can steal the clipboard data https://github.com/bugaevc/wl-clipboard
2018-10-16 20:11:29     emersion        ah, and serial is weirdly documented there
2018-10-16 20:12:04     -->     random_yanek (~random_ya@host-89-230-164-27.dynamic.mm.pl) has joined #wayland
2018-10-16 20:12:41     -->     mythos (~mythos@unaffiliated/mythos) has joined #wayland
2018-10-16 20:15:33     jadahl  emersion: probably because of sloppy focus checking in mutter
2018-10-16 20:16:14     emersion        i mean, you can get the clipboard data without having to send a serial
2018-10-16 20:16:40     emersion        get the data offer, call wl_data_offer::receive, done
2018-10-16 20:16:41     jadahl  right. the serial doesn't help. the compositor should just check for interaction that is newer than focus
2018-10-16 20:16:47     emersion        aye
2018-10-16 20:17:05     emersion        that makes sense

wl-paste relies on its surface stealing focus #12

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions