[13:15:35] ajax: hmm, what's /tmp/X[0-9]-lock actually used for? [13:15:49] kinda vulnerable to DoS [13:16:10] is that part of the API? [13:16:15] *** vovkkk (~vova@90.189.138.132) has joined chat #fedora-desktop. [13:16:17] ajax: or could that be moved intoa subdir? [13:16:28] that could be created at boot safely where only root can write to? [13:18:16] mezcalero: it's something i've been meaning to delete [13:18:42] it's supposed to be a mutex around the display number for OSes that are too stupid to prevent multiple binding to the same port, because that used to be a thing [13:19:58] *** mbarnes is now known as mbarnes|afk. [13:20:51] ajax: i see [13:21:09] files as mutexes suck [13:22:32] ajax: hmm, one more question, can i convince you guys to make the X11 server read the default kbd config directly from /etc/vconsole.conf? so that we can share console and x11 configuration up to a certain point? [13:23:16] it currently just has KEYMAP= in there, but we could extend this for more x-specific options [13:23:27] that we we wouldn't have to sync configuration anymore with kludges [13:24:46] mezcalero: I dont' think we have a clean separation between "what's printed on the keycaps" and "how the user has configured the keyboard" at the X level, and only the first really makes sense to sync [13:33:26] owen: well, the console is simple [13:33:35] so the console would only pick up the main keymap [13:33:39] and ignore the other settings [13:34:11] owen: so, what i was thinking is that the user configures whatever he wants to configure, and then he can click on a button to make that the system default [13:34:17] which would write it to /etc/vconsole.conf [13:34:34] readback? [13:35:04] the file would store all 20 settins X needs [13:35:35] the console would apply only 1 of those [13:35:38] x the rest of them [13:35:55] and x and the console would share the one central setting which is KEYMAP [13:36:17] note we already do this [13:36:23] (in the hope that the same identifiers are used there) [13:36:23] just with /etc/sysconfig/keyboard not /etc/vconsole.conf [13:36:36] halfline: well, and we have a daemon which syncs those files afaik [13:36:39] that's what the whole fedora-setup-keyboard tower iso [13:36:41] *is [13:36:45] yea [13:37:03] yes, and what i am proposing is that by standardizing /etc/vconsole.conf we'd have a good excuse to make X11 just read that directly [13:37:09] reads /etc/sysconfig/keyboard and write a file in xorg.conf.d [13:37:18] mezcalero: right [13:37:33] was just saying the idea in general works, since we're already doing it [13:37:51] if we can do it sans the hack tower that would definitely be a good thing [13:37:53] and of coruse systemd would then again have a mechanism for manipulating /etc/vconsole.conf from gnome cc [13:38:28] ajax: opinions on all of these ideas? [13:39:32] ajax: also, /tmp/.X11-unix is currently sticky and word writable. why? can we limit this to root? [13:40:23] i have little opinion on keyboard config, ask whot. [13:40:37] and no, you can't, if you want plain users to be able to start X servers [13:41:00] well, assuming we still bother to use the filesystem sockets. but you got all huffy when i mentioned we're using abstract sockets too. [13:41:47] i think abstract sockets should just be deprect ated [13:41:53] i think you're out of your mind. [13:41:54] there isn't really any benefit anymore in using them [13:42:10] unlink(). [13:42:28] for that matter, the need to have a writeable filesystem, period. [13:42:37] yupp, and we have that now in /run [13:42:44] which is available from initrd time on [13:43:28] writeable for who? [13:44:10] Xvfb as a normal user needs to work. where should that socket go? [13:44:26] sockets are for communication, so you want some kinda of reference to them. If you use abstract namespace sockets you cannot use the name itself to not create DoS vulnerabilities, so you need to store the name of the socket somewhere. one place would be a well known place in the fs. in which case you could place a socket there directly. or in an env var, but env vars suck since they serialize execution... [13:44:35] ajax: $XDG_RUNTIME_DIR [13:45:31] i think for almost all things having a well defined place in the fs is a better choice than using randomized abstract namespace sockets [13:45:37] it's a DoS for me no matter what though [13:45:45] all my socket numbers have to be correlated [13:45:47] and if they are not randomized (and X11's aren't) then you lost... [13:45:56] because they map to display numbers [13:46:10] yupp, i guess x is kinda broken there in a way that cannot be fixed easily... [13:46:21] :0 needs to be port tcpv4/6000 and tcpv6/6000 and /tmp/.X11-unix/X0 and @/tmp/.X11-unix/X0 [13:46:55] well we should get rid of hard coded display numbers too actually [13:46:59] i can use the -displayfd trick, but even then i still need to check against tcp [13:47:05] switch to -displayfd or whatever [13:47:28] ajax: is -displayfd upstream yet btw? [13:47:35] otherwise you can end up with two users both running a DISPLAY=:0 that can't see each other's servers, which is a real use case for some (admittedly weird) people [13:47:50] halfline: i don't even know anymore [13:47:57] every time i post it it gets bikeshedded to the ground [13:48:09] ugh [13:48:12] i miss having the power of god [13:48:13] socket actviated X11 is really difficult actually, hard to make work with gdm, where two users share a single X servr and we'd have to move the socket between their dirs [13:48:54] i.e. before you login the socket is owned by the gdm user, afterwards by the logged in user [13:48:57] and that's why we have globally visible names and cope with the DoS potential. [13:49:34] -displayfd basically fixes the DoS and after that just deal with it being global. [ weeks later ] [10:39:35] mezcalero: hey, I looked into socket activation for Xorg [10:42:49] mezcalero: and creates a lock file before creating the socket - how would you handle that? [10:42:56] *X creats [11:04:51] krh: http://people.freedesktop.org/~halfline/x-lock-files.txt [11:33:12] krh: i discussed socket activation for X a couple of weeks ago with ajax [11:33:24] and we basically came to the conclusion that it's not really doable [11:33:44] it's more or less incompatible with the way x assigns port numbers [11:33:57] since it wants the port number and the unix sockets to always be in sync [11:34:09] and it goes and looks for the first port it finds that way [11:34:21] that logic doesn't really have a place in systemd i would say [11:34:44] i figure macosx pulls this off because it says there are no dynamic display names, and only :0 [11:34:52] which of courses simplifies things drastically [11:35:40] i don't think we could implement X11 socket activation without teaching systemd somehow to iterate through the port numbers and find a free one and do that in sync for the unix sockets and IP [11:36:06] and i am not sure i want x11-specific code like that in systemd... [12:09:23] mezcalero: yeah, that's what I did in a custom-hack [12:09:49] I just iterate through the display numbers until i find one without a lock file and socket [12:10:05] then create that and pass the fd and the display number when launching X [12:10:39] but you're right, it's not easy to make systemd do that without an X specific mechanism