ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
<pq>
when you do a clamp() only to cater for potential floating-point imprecision in computations, how would you name the clamp function to differentiate it from other reasons to clamp?
<pq>
or how would you neatly "document" in the code that this clamp is only for imprecision and not intended to significantly change the value?
<emersion>
the Wayland way would be to slap a _safe suffix
<pq>
ahaha
<pq>
I started thinking safety_clamp()...
<swick>
slop?
<swick>
slack?
<pq>
wouldn't that be more like... adding slop?
<pq>
clamp_slack()?
<swick>
I guess its removing slack?
<swick>
meh, I'm not good at naming things. supposedly it's a hard problem.
<pq>
yeah, since we are clamping to a range only because FP computation might produce insignificantly out-of-range
<kennylevinsen>
duct_tape() - weaker than a clamp(), but strong enough.
naveenk2 has quit []
<pq>
can't think of anything better than safety_clamp() really, since it's just-in-case
<pq>
but yeah, it is kind of duct tape, or paper
<pq>
let's call it paperclip() and everyone will be equally baffled :-P
<ManMower>
sigh. Now I'm gonna have "safety dance" stuck in my head all day. /* We can clamp if we want to o/~ */
<jadahl>
safety dance?
<ishitatsuyuki>
guess it's a noob question, but is "popup window" a common term? In xdg-shell it's used to mean "menus, tooltips etc" and it also seems to be used for the same meaning in KWin, but coming from a webdev background I can only think of pop-up windows as those additional browser windows that gets blocked nowadays
<mceier>
pq: what's the difference in the implementation ? would it be just an alias for clamp ? if not, can clamp return insignificantly out-of-range value ?
<jadahl>
ManMower: let me know if you need a citizen to sponsor ;p
<ManMower>
:D
<pq>
ishitatsuyuki, there is xdg_popup for some specific purposes, and then there is the generic term that could refer to any sudden (and short-lived?) window that is more or less not an application main window.
<ishitatsuyuki>
yeah, you're right
<mceier>
pq: nothing makes code more obvious than a comment next to it ;) I think having 2 clamp functions with exactly the same implementation would be more confusing and beg the question - how clamp is less safe than safe_clamp when they're exactly the same ? when someone should use safe_clamp and when clamp ?
<pq>
not safe_clamp() but safety_clamp()
<pq>
that clamp is not what is or isn't safe
<pq>
(there also isn't a normal clamp so far)
<pq>
I want to avoid adding the same comment in every place where I call the function.
<ManMower>
stochastic_procrustean_reducer()
<mceier>
ensure_in_range() ?
<pq>
ooh, I like that direction
<pq>
thanks!
<mceier>
yw :)
leon-p has quit []
jgrulich has quit [Ping timeout: 480 seconds]
<pq>
hmm, float ensure_unorm(float x)
<pq>
might have a winner
<ManMower>
glad to have been on this journey with you :)
<ManMower>
definitely much more descriptive than "safety_clamp".
<Serus>
I'm new to wayland, but as far as I understand wayland is "just" an API specification?
<Serus>
Kinda like OpenGL?
<wb9688>
It is just a specification
<wb9688>
Like how HTTP has many different implementations of servers and clients
<wb9688>
In Wayland the server would be your compositor (like Sway/Wayfire/GNOME) and the client would be your GTK/Qt/whatever app
zebrag has joined #wayland
yukke has joined #wayland
tzimmermann has joined #wayland
yukke has quit []
<kennylevinsen>
A specification (XML files) and a C library implementing the wire protocol (but none of the business logic)
<ifreund>
well I mean, wl_display/wl_registry/wl_shm do business logic
MrCooper has quit [Quit: Leaving]
boistordu has quit [Remote host closed the connection]
boistordu has joined #wayland
<ifreund>
though there's 0 reason to implement those differently for most wayland servers/clients
MrCooper has joined #wayland
<Serus>
Right
<Serus>
So in that sense, would it be possible to implement something like UAC using Wayland? Assuming the spec would allow for this.
<Serus>
More specifically, windows runs a very limited session for the UAC popup, basically only privileged users and drivers could possibly touch that session afaik
<Serus>
And then I assume it's just displayed over the current user session
<Serus>
I think you could do something similar with pkexec, but I'm not too sure about the limiting of session capabilities
<Serus>
Basically what I would want to implement is a running a limited session in a different tty and then have the system automatically switch to it whenever a program is asking for root permissions
<Serus>
is running a*
naveenk2 has quit []
<ManMower>
I think none of the session/tty switching logic is helped by wayland at all
<Serus>
Well that is not something wayland would be concerned with no
<Serus>
What I mean more is something along the lines of blitting a session over another one
<pq>
Serus, no, you really are looking at hand-over between two different Wayland compositors.
<Serus>
Alternatively you could take a screenshot, move to the other session/tty and show a blurred version as the background
<ManMower>
yeah, none of the hard bits of this are solved (or even considered) by wayland
<Serus>
It doesn't have to be solved, if it was, I assume it would be in use
<Serus>
My question is more does the spec allow for something like this to happen
<pq>
you could already implement UAC in a Wayland compositor, without need Wayland at all. But then, that would not be any more trusted that the normal compositor is. But sometimes it might be enough.
<MrCooper>
FWIW, with GNOME, things like polkit authentication dialogues are handled by gnome-shell itself (presumably via D-Bus?)
<pq>
Serus, I think the answer to that question is: Wayland is not relevant to the question.
<ManMower>
pq: thanks, that's what I'm trying to say too
<Serus>
Right
<ManMower>
Serus: there's nothing in the protocol that would aid or prevent what you want
<Serus>
I don't know much about wayland, only hearsay and what I saw in presentations years ago
<Serus>
One of those being "X is insecure, wayland aims to fix this"
naveenk2 has joined #wayland
<Serus>
ManMower: that last part is important to me
<Serus>
As long as there is nothing stopping me from doing this
<ManMower>
fair enough
<Serus>
MrCooper: I will have to look into that
<ManMower>
I think your largest changes will be to your session management software (systemd? seatd?)
<pq>
Serus, in both Wayland and X11, the dispaly server is a fundamentally trusted actor. Is that ok for you, or do you not trust a display server running as your regular user that much?
<Serus>
As currently things like gksu would still be vulnerable to keyloggers running in the current session
<pq>
the problem with X11 that Wayland "solves" is that any X11 is usually allowed to whatever they like, including spying. And that does not even require compromising anything, it's just how it works.
<pq>
so if your attack vector is random apps that might spy your input, then the Wayland architecture is already safe in that Wayland protocol has no provision for spying.
<Serus>
afaik you're still vulnerable to LD_PRELOAD attacks
<pq>
but it still requires that you trust your display server (Wayland compositor)
<pq>
Serus, that's totally outside of any display protocol scope
<pq>
Serus, you can often just attach gdb to a running process and change memory at will, too.
<Serus>
that is true I suppose
<emersion>
"but HTTP is vulnerable to XSS attacks!"
<emersion>
"fix HTTP!"
<Serus>
pq: so in a vacuum something like "UAC for Linux" is not needed for wayland?
<Serus>
I am also talking about userspace "drivers", e.g. a mouse program like you get with a logitech/razer mouse on windows
<pq>
Serus, I don't understand the question. None of those can exist in a vacuum.
<Serus>
Well, you say something like an LD_PRELOAD attack is out of scope for wayland
<pq>
yes, Wayland has nothing to do with how processes get executed or binaries get linked.
<pq>
Wayland is about how an application talks with a display server in order to display stuff and get input.
<Serus>
So in a vacuum, meaning disregarding stuff like LD_PRELOAD, MAC, other restrictions from the outside, wayland shouldn't need something like switching to a locked down session to input a password
<Serus>
right?
<pq>
Serus, Wayland does not have a concept of passwords or even password dialogs. I'm missing something in your question.
<pq>
Wayland does not define where the input events come from, and it does not define where they go. It only defines how they are transmitted.
<ManMower>
Serus: is your attacker running as root?
<pq>
Since Wayland does not define any mechanism to "spy" on input events, spying on input via Wayland is not possible.
<Serus>
ManMower: no, the restriction is to prevent an attacker from sniffing the sudo password
<pq>
you would need a compositor bug for the compositor to be sending input events to a Wayland client that is not supposed to get them.
<Serus>
right
<Serus>
so could a wayland client send input to the compositor? like a mouse/keyboard macro?
<ManMower>
if your attacker has inserted an LD_PRELOAD shim before the launch of the terminal app you're running sudo in, all hope is lost
<Serus>
As a possible attack would be to launch a malicious program as root via something like gksu, and then move the mouse to the "ok" button hoping the password is cached
<ManMower>
if the attacker can run anything as root, all hope is lost
<Serus>
yes
<Serus>
but in windows you don't need root to take over the mouse
<Serus>
so what windows does is run the UAC prompt in a session where an attacker cannot take over the mouse/keyboard
<Serus>
If an attacker can still have access to the mouse/keyboard when the graphical sudo prompt is open, you might as well be root
<ManMower>
UAC is that thing I turn off so my samba connections don't randomly disconnect while I'm copying files, right?
<Serus>
I never had that issue
<ManMower>
it's somewhat complicated to trigger ;)
<Serus>
Users turning it off is part of their freedom to do with their system what they want, if they want to disable all security measures in their system that's their right
<ManMower>
if you're concerned about an app running as the current user logging all their keystrokes, that's probably a valid concern
<ManMower>
it wouldn't take place through wayland
<ManMower>
but via proc, ptrace, etc etc
<Serus>
afaik most distros restrict ptrace to root alreadu
<Serus>
already*
<ManMower>
well, I only use a couple of distros (debian/fedora) and they don't
<ManMower>
but I'm sure you could configure your system as such
<Serus>
oh I see
<Serus>
It is on arch linux, and afaik gentoo as well
<Serus>
either way, is there anything in the wayland protocol that allows for injecting input?
<Serus>
I would assume (global) hotkeys come from the compositor
<ManMower>
I think there's a test protocol that nobody ships that we use for injecting in CI, but I'm unaware of anything that would be installed on a sanely managed distro
<pq>
Serus, Wayland does not have a standard interface for client to send input to anything. Not to the compositor, nor to other clients.
<Serus>
right, I see
<Serus>
so by design "macro" programs are out of the question I suppose
<Serus>
Can't say I disagree with that
<ManMower>
the compositor does macros
<ManMower>
it has caused stress for many potential users, but it's one of wayland's design goals
<Serus>
do you mean like hotkeys? Or "move mouse to X,Y, click, wait 100ms; move mouse to x,y; click; done"?
<ManMower>
any of the above
<ManMower>
though I can't see someone adding code to a compositor to do the latter
<emersion>
well, we've done it.
<emersion>
(sway)
<Serus>
I can't say I ever needed something like that on Linux, but definitely had to do something like that to solve repetitive tasks on Windows
<ManMower>
Serus: btw, I was somewhat around about ptrace. there are programs running as my userid that I'm not allowed to ptrace. and in regards to your question as to whether "something like UAC" is necessary, I'm not certain about that particular implementation, but I suspect with proper configuration and available software you'll get un-man-in-the-middle-able authentication popups even for sudo launched from
<ManMower>
a terminal
<Serus>
well, I think you already can do that via pkexec
<Serus>
you can do a "proof of concept" locally by typing $$ in a terminal
<Serus>
opening up another terminal and typing pkttyagent --process pid_here
<Serus>
and then pkexec vim in the first terminal
<Serus>
so pkexec's agent can run in a different session
naveenk2 has quit []
Arnavion has quit [Remote host closed the connection]
<kennylevinsen>
I think the main conclusion here is that UAC is not generally necessary, but if a compositor dies implement virtual input, it could make a UAC style polkit agent if it so desired, as it is always free to decide how input works and is routed.
<kennylevinsen>
s/dies/does/
<kennylevinsen>
wlr-layer-shell plus some "no fake input plz" protocol could be used to present such a UI from a normal application
<kennylevinsen>
Although this will play poorly with vnc/rdp which uses virtual input to operate the session...
Guest1597 has quit [Read error: Connection reset by peer]
Arnavion has joined #wayland
ziky has joined #wayland
rektide has quit [Remote host closed the connection]
<wb9688>
Doesn't GNOME Shell have polkit inside the compositor?
Narrat has joined #wayland
kennylevinsen has left #wayland [#wayland]
tzimmermann has quit [Ping timeout: 480 seconds]
kennylevinsen has joined #wayland
xexaxo has quit [Ping timeout: 480 seconds]
<jadahl>
wb9688: polkit is a daemon. gnome-shell is an agent that can query the user on behalf of polkit