| 00:04.23 | gnarface | stevelitt: stuff is gonna be different enough that old configs in your home directory can cause userspace damage that may look just like a broken system until you purge the old configs (VLC is a frequent offender in this regard, but hardly the only one) |
| 00:05.04 | gnarface | in general it might be safer to upgrade from a headless, minimal ascii install than something you've already worked to configure the user environment for |
| 00:05.20 | gnarface | the version of Xorg in there isn't even compatible with the same range of NVidia drivers, i don't think |
| 02:18.28 | *** join/#devuan infobot (ibot@208.53.50.136) |
| 02:18.28 | *** topic/#devuan is This is the Devuan https://devuan.org/ discussion channel | **You need to auth to nickserv to talk!** | Latest (2018-06-09): ASCII 2.0.0 https://devuan.org/os/debian-fork/ascii-stable-announce-060818 || Stable (2017-05-25): Jessie 1.0.0 LTS release | Devuan Forum: https://dev1galaxy.org/ | Chanlogs: http://maemo.cloud-7.de/irclogs/freenode/_devuan/ https://botbot.me/freenode/devuan |
| 02:18.28 | *** mode/#devuan [+v infobot] by ChanServ |
| 02:24.57 | *** join/#devuan gotgnu (~someone@pdpc/supporter/active/gotgnu) |
| 02:58.09 | *** join/#devuan ferdy-1 (~ferdy@net-2-34-225-10.cust.vodafonedsl.it) |
| 02:58.09 | *** join/#devuan ferdy-1 (~ferdy@funtoo/contrib/ferdy-) |
| 03:01.43 | *** join/#devuan pankerini (~pankerini@189.230.95.12) |
| 03:03.42 | *** join/#devuan nailyk (~nailyk@carbonfusion/co-admin/nailyk) |
| 03:05.47 | *** join/#devuan rafalcpp (~racalcppp@84-10-11-234.static.chello.pl) |
| 03:12.52 | *** join/#devuan drawkula (~username@pD9F4EDF6.dip0.t-ipconnect.de) |
| 03:17.55 | *** join/#devuan furrywolf (~furrywolf@172.58.38.231) |
| 03:24.08 | *** join/#devuan ffurrywol (~furrywolf@172.58.38.231) |
| 03:51.25 | *** join/#devuan targz (~Thunderbi@unaffiliated/targz) |
| 04:06.47 | *** join/#devuan pankerini (~pankerini@189.230.95.12) |
| 04:12.35 | *** join/#devuan nailyk (~nailyk@carbonfusion/co-admin/nailyk) |
| 04:34.02 | *** join/#devuan Digitteknohippie (~user@fsf/member/digit) |
| 04:37.49 | *** join/#devuan ymasson (~ymasson@lfbn-1-8785-102.w193-250.abo.wanadoo.fr) |
| 04:44.54 | *** join/#devuan nailyk (~nailyk@carbonfusion/co-admin/nailyk) |
| 04:49.00 | *** join/#devuan fleeky (~fleeky@75-101-60-65.dsl.static.fusionbroadband.com) |
| 04:59.36 | *** join/#devuan Digit (~user@fsf/member/digit) |
| 05:00.00 | *** join/#devuan fleeky (~fleeky@75-101-60-65.dsl.static.fusionbroadband.com) |
| 05:09.49 | *** join/#devuan nailyk (~nailyk@carbonfusion/co-admin/nailyk) |
| 05:14.02 | *** join/#devuan nailyk (~nailyk@carbonfusion/co-admin/nailyk) |
| 05:22.13 | *** join/#devuan Wasp (~wasp@gruenau4.informatik.hu-berlin.de) |
| 05:26.19 | *** join/#devuan nailyk (~nailyk@carbonfusion/co-admin/nailyk) |
| 05:36.28 | *** join/#devuan golinux (~golinux@2a03:b0c0:2:d0::f7:f001) |
| 05:36.28 | *** join/#devuan golinux (~golinux@devuan/developer/golinux) |
| 06:01.52 | *** join/#devuan Besnik_b (~Besnik@ppp-94-66-221-119.home.otenet.gr) |
| 06:16.06 | *** join/#devuan nailyk (~nailyk@carbonfusion/co-admin/nailyk) |
| 06:38.46 | *** join/#devuan AntoFox (~Thunderbi@37.160.63.134) |
| 06:39.04 | *** join/#devuan ravencrow (~raven_cro@172.111.163.230) |
| 06:56.25 | *** join/#devuan nailyk (~nailyk@carbonfusion/co-admin/nailyk) |
| 07:01.49 | *** join/#devuan amarsh04 (~amarsh04@ppp121-45-27-183.bras1.adl4.internode.on.net) |
| 07:09.58 | *** join/#devuan nailyk (~nailyk@carbonfusion/co-admin/nailyk) |
| 07:12.19 | *** join/#devuan amarsh04 (~amarsh04@ppp121-45-27-183.bras1.adl4.internode.on.net) |
| 07:21.35 | *** join/#devuan HalfWord (~halfword@unaffiliated/halfword) |
| 07:39.34 | *** join/#devuan nezos (~nezos@2001:648:2800:25:76d4:35ff:fe80:be52) |
| 07:44.02 | *** join/#devuan amarsh04 (~amarsh04@ppp121-45-27-183.bras1.adl4.internode.on.net) |
| 07:44.19 | *** join/#devuan Human_G33k (~HumanG33k@62.147.242.8) |
| 07:48.04 | *** join/#devuan Gup (~Gup@jh3.jhodges.co.uk) |
| 08:00.18 | *** join/#devuan nailyk (~nailyk@carbonfusion/co-admin/nailyk) |
| 08:04.03 | *** join/#devuan Human_G33k (~HumanG33k@62.147.242.8) |
| 08:11.46 | *** join/#devuan clemens3_ (~clemens@mx.eniso-partners.com) |
| 08:15.56 | *** join/#devuan clemens3 (~clemens@mx.eniso-partners.com) |
| 08:16.20 | *** join/#devuan nailyk (~nailyk@carbonfusion/co-admin/nailyk) |
| 08:20.18 | *** join/#devuan allohol (Elite21154@gateway/shell/elitebnc/x-sbcbjovpkbhtsvuk) |
| 08:26.51 | *** join/#devuan ErRandir (~mhabets@81.168.73.77) |
| 08:27.49 | *** join/#devuan nailyk (~nailyk@carbonfusion/co-admin/nailyk) |
| 09:12.48 | furrymcgee | how can devuan used as freeipa-server the package is missing in the repository |
| 09:20.12 | *** join/#devuan cyteen (~cyteen42_@222.209.125.91.dyn.plus.net) |
| 09:39.22 | *** join/#devuan negev (~mark@88.97.100.192) |
| 09:39.42 | negev | hai |
| 09:39.52 | negev | openssl 1.1.1 seems to cause issues with some stuff |
| 09:39.54 | negev | eg: https://gist.github.com/m4rkw/84eb64d60a6ec5b9379cb834a7394e99 |
| 09:40.12 | negev | i can't find libssl_conf.so anywhere on the system with either 1.1.0f or 1.1.1 |
| 09:40.24 | negev | it's not referenced in the openssl.cnf or in ldd output for phantomjs |
| 09:45.28 | man_in_shack | flails |
| 09:45.37 | man_in_shack | got me my bluray discs playing over iscsi |
| 09:45.47 | man_in_shack | not dvds because fuck css encryption shit |
| 09:45.59 | rrq | ngev: how about https://github.com/drwetter/testssl.sh/issues/1117#issuecomment-418508290 |
| 09:47.19 | negev | rrq: i saw that but i don't really understand it |
| 09:48.39 | rrq | suggests that you set OPENSSL_CONF to pinpoint your openssl.cnf |
| 09:49.27 | negev | but i only have one openssl.cnf anyway |
| 09:49.30 | negev | how would that help? |
| 09:50.36 | gnarface | man_in_shack: the libdvdcss2 from videolan.org works for general purpose |
| 09:50.41 | negev | ah, using the openssl.cnf from manually compiled openssl 1.1.1 seems to work |
| 09:51.14 | man_in_shack | gnarface: yah but tgt seems to have trouble reading the encrypted packets and passing that over to libdvdcss :) |
| 09:51.32 | gnarface | you sure you didn't just forget libdvdnav4? |
| 09:51.37 | man_in_shack | yes |
| 09:52.06 | man_in_shack | let me doublecheck |
| 09:52.25 | man_in_shack | yah it's installed |
| 09:53.24 | man_in_shack | does look like it's tgt's fault |
| 09:53.26 | man_in_shack | (: |
| 09:54.16 | man_in_shack | so what i doing is running a remote X server with vlc in |
| 09:54.25 | man_in_shack | cos the 10 year old core2 duo can handle that |
| 10:23.33 | *** join/#devuan nighty- (~nighty@s229123.ppp.asahi-net.or.jp) |
| 10:25.20 | *** part/#devuan pm215 (petmay01@linaro/pm215) |
| 10:44.04 | *** join/#devuan Chain|Q (~charlie@berlin.coderetro.net) |
| 10:55.25 | *** join/#devuan cyteen (~cyteen42_@222.209.125.91.dyn.plus.net) |
| 11:01.22 | *** join/#devuan unixman_home (~unixman2@36-112-35-72.mtaonline.net) |
| 11:01.58 | *** join/#devuan unixman_home (~unixman2@unaffiliated/eracc) |
| 11:16.36 | *** join/#devuan sirix (Elite16648@gateway/shell/elitebnc/x-pygzqlyaogvmwdmq) |
| 11:17.41 | *** join/#devuan petris_ (quassel@li-web.host.petris.net) |
| 11:18.38 | *** join/#devuan waydot (~loot@2a01:260:4117:1234:5678:9abc:def0:0) |
| 11:18.49 | *** join/#devuan doppo (doppo@2604:180::e0fc:a07f) |
| 11:23.12 | *** join/#devuan hiei (jinzo@gateway/shell/elitebnc/x-sxkuwvmaxzaauuzi) |
| 11:28.34 | *** join/#devuan saptech (~saptech@unaffiliated/saptech) |
| 11:29.20 | *** join/#devuan Hurgotron (~Hurgotron@kabelmarder.de) |
| 12:01.44 | *** join/#devuan Guest89553 (nemo@hedgewars/dev/nemo) |
| 12:19.48 | *** join/#devuan Ryushin (~Ryushin@windwalker.chrisdos.com) |
| 12:27.37 | *** join/#devuan Half-Word (~halfword@unaffiliated/halfword) |
| 12:34.37 | *** join/#devuan justinsm (~justinsm@82-69-63-196.dsl.in-addr.zen.co.uk) |
| 13:01.57 | *** join/#devuan elacheche (5a5c08aa@gateway/web/freenode/ip.90.92.8.170) |
| 13:35.30 | *** join/#devuan Acacia (~Acacia@unaffiliated/acacia) |
| 13:48.49 | *** join/#devuan VlijmenFileer (~VlijmenFi@2001:981:8451:1:67c6:df8:5c41:4b33) |
| 14:23.11 | *** join/#devuan pankerini (~pankerini@189.230.95.12) |
| 14:31.55 | *** join/#devuan g4570n (~g4570n@unaffiliated/g4570n) |
| 14:31.57 | *** join/#devuan targz (~Thunderbi@unaffiliated/targz) |
| 14:36.38 | *** join/#devuan rafalcpp_ (~racalcppp@84-10-11-234.static.chello.pl) |
| 14:39.31 | *** join/#devuan queip (~queip@unaffiliated/rezurus) |
| 15:12.37 | *** join/#devuan cyteen_ (~cyteen42_@222.209.125.91.dyn.plus.net) |
| 15:17.13 | *** join/#devuan cyteen (~cyteen@222.209.125.91.dyn.plus.net) |
| 15:17.42 | *** join/#devuan Kohlrabi (~kohlrabi@kohlio.de) |
| 15:22.29 | *** join/#devuan _systemd_is_evil (~NOsystemd@unaffiliated/mailjesus) |
| 15:26.30 | *** join/#devuan _systemd_is_evil (~NOsystemd@unaffiliated/mailjesus) |
| 15:29.11 | *** join/#devuan Akuli (~akuli@mobile-access-bceea2-116.dhcp.inet.fi) |
| 15:29.11 | *** join/#devuan RedAcor (~RedAcor@gateway/tor-sasl/redacor) |
| 15:36.21 | *** join/#devuan Leander (~Leander@132.147.84.158) |
| 15:50.04 | *** join/#devuan rustyr (~rustyr@dslb-088-066-217-110.088.066.pools.vodafone-ip.de) |
| 15:53.14 | *** part/#devuan elacheche (5a5c08aa@gateway/web/freenode/ip.90.92.8.170) |
| 15:57.14 | *** join/#devuan minnesotags (~herbgarci@64.241.45.209) |
| 16:01.15 | plasma41 | Good Morning |
| 16:06.26 | *** join/#devuan _abc_ (~usre@unaffiliated/ccbbaa) |
| 16:07.29 | _abc_ | Hi. Is the patched xorg alredy in the devuan updates package stream for ascii? I find it confusing that I have to ask about this knowing "upstream" is always official debian... |
| 16:08.00 | plasma41 | What patch is this? |
| 16:08.06 | _abc_ | #2: I lol'd at the thought Poettering may end up wearing a suit to work. IBM bought Red Hat. I am curious how these two cultures will clash. They are like fire and water. |
| 16:08.41 | _abc_ | plasma41: the security patch for the bug which permits overwriting any system file by a user starting xorg with crafted log file list. |
| 16:09.24 | plasma41 | I hadn't heard about that bug |
| 16:09.44 | _abc_ | https://www.bleepingcomputer.com/news/security/trivial-bug-in-xorg-gives-root-permission-on-linux-and-bsd-systems/ well now you have |
| 16:11.21 | _abc_ | devuan ascii has xorg 1.19.2 and is vulnerable. |
| 16:16.07 | _abc_ | https://www.youtube.com/watch?v=qPlVNjUq_hU interview with Poettering, in German. In the 1st 2 minutes he says systemd is hopefully better since "we tried to get the best parts of the Apple OS init system, and from Solaris's sms". Tried. And still trying. Right. |
| 16:16.16 | _abc_ | I find it super amusing he's now an IBM employee. |
| 16:16.30 | nemo | I thought that bug was embargoed to allow distros to fix |
| 16:16.39 | nemo | surely debian would have done so? |
| 16:16.59 | _abc_ | I think IBM made one project on someone's "knee" once in it's history, with no ties attached and no control over developers. That was the IBM PC project, as I read it. |
| 16:17.15 | _abc_ | nemo: Do you auto update? I don't. |
| 16:17.38 | nemo | $ ls -l /usr/bin/Xorg |
| 16:17.38 | nemo | -rwxr-xr-x 1 root root 274 Oct 14 2017 /usr/bin/Xorg |
| 16:17.41 | nemo | not suid |
| 16:17.46 | nemo | no idea when it stopped being suid |
| 16:17.49 | nemo | maybe never was |
| 16:18.03 | nemo | _abc_: that's what pissed off the BSD folks since they would have dropped that on theirs had they been alerted |
| 16:18.05 | *** join/#devuan James1138 (~james1138@71-32-87-133.tukw.qwest.net) |
| 16:18.45 | nemo | _abc_: I imagine for most setups running X without suid is a pretty sensible default. so could have been that way for years |
| 16:18.52 | nemo | actually surprised BSD didn't do that |
| 16:19.55 | nemo | _abc_: https://wiki.gentoo.org/index.php?title=Non_root_Xorg&action=history gentoo's page on this dates back to 2014 |
| 16:24.43 | nemo | _abc_: https://www.phoronix.com/scan.php?page=news_item&px=Debian-Non-Root-X |
| 16:24.46 | nemo | 2015 |
| 16:27.32 | _abc_ | The hole is indeed 2 years old. |
| 16:28.12 | _abc_ | Xorg stopped being suid a long time ago but that does not change things. Try ps -auxwf and look for xorg in the tree. |
| 16:28.55 | _abc_ | On my ascii Xorg is executed by slim and runs as root |
| 16:29.26 | _abc_ | The config files which are partly user specifiable at start time can be modified by the user to make Xorg log to key system files instead, and clobber them. |
| 16:30.06 | nemo | _abc_: ah you're right. crud. |
| 16:30.24 | nemo | _abc_: well I know about the age of the hole and the risk, I just assumed suid :/ |
| 16:30.32 | nemo | didn't think they'd be running a wrapper helper |
| 16:30.53 | _abc_ | Again: non suid Xorg running since 1.17, bug since 1.19 |
| 16:31.27 | _abc_ | It does not matter what they run while the philosophy of the Xorg is to accept config files added by the executing user anywa. |
| 16:31.31 | _abc_ | y as root. |
| 16:31.53 | nemo | um... what's that "Again" about? how are we contradicting |
| 16:32.15 | nemo | you're right about the root thing. it's just surprising since I thought they were trying to get rid of that, as the phoronix article notes |
| 16:33.08 | _abc_ | The setsuid Xorg binary is no longer setsuid since 1.17. The current bug appeared in 1.19 |
| 16:33.37 | _abc_ | Back to IBM bearhugging RH: https://www.theregister.co.uk/2017/08/23/red_hat_microsoft_container_alliance/ |
| 16:33.50 | nemo | yeah, I'm just confused as to why they would remove setuid and still run Xorg as root |
| 16:33.54 | nemo | that seems to totally defeat purpose |
| 16:34.17 | _abc_ | IBM ceo said that the new merge will "change the way container runners work". I am curious. Usually IBM does not lob tasty morsels towards M$. |
| 16:34.36 | _abc_ | nemo: it is executed by the login manager which acts as a wrapper. |
| 16:34.43 | _abc_ | slim in my case |
| 16:35.24 | nemo | aaaanyway |
| 16:35.42 | nemo | _abc_: yeah. that is obv. I don't get the WHY ð |
| 16:35.45 | nemo | aaaaaaaanyway |
| 16:35.47 | nemo | https://launchpad.net/debian/+source/xorg-server/+changelog |
| 16:35.57 | nemo | clearly debian does NOT have the CVE fixed in 1.19 â¹ |
| 16:36.05 | nemo | there's no evidence of it anywhere in the changelog apart from 1.20 |
| 16:36.22 | nemo | at least it's "just" local â¹ |
| 16:36.36 | nemo | not that that helps multiuser setups at all |
| 16:37.31 | _abc_ | chnagelog for 1.19.2-6 seems to imply a lot of OTHER holes were also present and sanitized with that release. |
| 16:37.46 | _abc_ | And I am not on that, but I am willing to bet that that is the upgrade path for 1.19.2 on ascii |
| 16:37.58 | nemo | _abc_: hmmm |
| 16:38.11 | nemo | _abc_: do you think since it was a security bug the CVE was not mentioned in the changelog? |
| 16:38.15 | nemo | it was embargoed and all |
| 16:38.21 | nemo | so 1.20 only shows it due to being post-announce.. |
| 16:38.27 | muep | so is Xorg installed with suid in Debian? my impression is that it is without suid |
| 16:38.59 | nemo | muep: it's without suid yes. the confusing part (to me) is why the login manager would still run it as root, instead of user privs |
| 16:39.13 | nemo | or a restricted account for the actual login manager itself |
| 16:39.47 | nemo | _abc_: I guess the only way to know for sure would be for me to debsrc my existing .deb and actually check the affected area |
| 16:39.52 | _abc_ | dpkg -l xserver-xorg -> 1:7.7+19 ?! |
| 16:39.59 | nemo | ?? |
| 16:40.04 | muep | nemo: AFAIK it is just the traditional way to have the login manager running as root |
| 16:40.50 | muep | it will still launch the desktop session processes with an unprivileged account when someone logs in |
| 16:40.53 | _abc_ | muep: Xorg is not suid but it's manager calls it up as root |
| 16:41.07 | nemo | muep: does that actually insulate against this bug? seems unlikely |
| 16:41.16 | nemo | muep: and why trust X that much - why not just drop all privs |
| 16:41.18 | nemo | shrugs |
| 16:41.22 | muep | nemo: do you udnerstand how the bug works? |
| 16:41.55 | _abc_ | How does one list the actual installed version of the deb not of the contents? |
| 16:42.09 | muep | dpkg -l somepackage |
| 16:42.33 | nemo | muep: so... I read the announcements, but my knowledge of X itself? nowhere near good enough to know how one might exploit it |
| 16:42.39 | nemo | muep: besides the mentioned commandline |
| 16:42.40 | _abc_ | I just did that. But the actual version of Xorg is sussed out by: sudo Xorg -version |
| 16:42.49 | _abc_ | And THAT is 1.19.2 here |
| 16:43.20 | nemo | muep: X is a big tangled mess to me, and would not surprise me at all if that module loading can be done in some API or X protocol thingy and not just commandline |
| 16:43.20 | _abc_ | Specifically: xorg-server 2:1.19.2-1+deb9u2 |
| 16:43.41 | _abc_ | Why did debian have to add new and unconnected package versioning and hide the actual program's versions? |
| 16:44.14 | *** join/#devuan yap (~yap@unaffiliated/yap) |
| 16:44.25 | yap | salve |
| 16:44.34 | muep | nemo: my impression is that the problem is not because X runs as root. as usual with SUID binaries, the problem is the automatic transition from a non-privileged user to a privileged one, combined with the privileged process doing wrong things when the unprivileged caller provides suitable input |
| 16:44.34 | _abc_ | Do you see how *useful* being able to see the actual program version is now? Looking in aptitude or whatever? |
| 16:44.59 | muep | _abc_: that is 1.19 isn't it? |
| 16:45.09 | nemo | yeah. I don't get what he's talking about... 1.19.2-1+deb9u2 |
| 16:45.10 | *** join/#devuan furrywolf (~furrywolf@172.58.38.151) |
| 16:45.27 | _abc_ | muep: which "that". The deb package isn't. It's 1:7.7+19 |
| 16:45.29 | nemo | where typically everything past the dash is debian's stuff |
| 16:45.37 | nemo | _abc_: xserver-xorg-core |
| 16:45.57 | *** part/#devuan plasma41 (~plasma41@72.34.178.42) |
| 16:45.58 | *** join/#devuan icavot (~icavot@84.105.223.87.dynamic.jazztel.es) |
| 16:46.03 | nemo | _abc_: the other one is https://www.x.org/wiki/Releases/7.7/ presumably |
| 16:46.59 | _abc_ | At least you are right in that xserver-xorg does not provide Xorg, -core does. |
| 16:47.02 | nemo | _abc_: xorg folks have their own separate server versioning so makes sense debian would use it too |
| 16:47.06 | muep | _abc_: ah, I did not notice that other one. but yep it seems that X.org has some version for the X server and other version numbers for other things they release alongside it |
| 16:47.13 | nemo | mhm |
| 16:47.27 | nemo | muep: mentioned right in that 7.7 release announce actually, 1.12 server release |
| 16:47.31 | _abc_ | muep: yes, so I was barking up the wrong tree, sort of. |
| 16:48.09 | muep | but really I do not see how you would use the setup with login manager running as root, to exploit this bug |
| 16:48.14 | nemo | aaanyway. fetching deb-src of xserver-xorg-core 1.19.2-1+deb9u2 would end all the speculation ⺠|
| 16:48.50 | *** join/#devuan Tom-_ (~tomg@64-7-147-192.agas1a-dynamic.dsl.sentex.ca) |
| 16:49.02 | nemo | muep: I have nooooo idea, but I'm also don't know a ton about just what X exposes where - my familiarity with its internals is low enough that I'd rather be patched or the server dropping privs ⺠|
| 16:49.10 | muep | at least the trivial case of an unprivileged user being able to launch the privileged X server process with arbitrary cmdline args is not available |
| 16:49.10 | nemo | muep: but yes, if it is ONLY commandline then no suid avoids |
| 16:49.13 | nemo | yep |
| 16:49.15 | *** join/#devuan kts (~kts@45.112.177.48) |
| 16:49.28 | muep | nemo: you do not need to understand X.org internals at all to understand this bug |
| 16:49.39 | *** join/#devuan IoFran (~Thunderbi@189.154.68.95) |
| 16:49.49 | nemo | muep: I understand the bug just fine. what I don't know is if that's the only pathway |
| 16:49.52 | nemo | that was my only point |
| 16:50.04 | nemo | or let's say, I read the diff and the explanation of how it was fail. |
| 16:50.08 | muep | of course there may be some other bugs in X.org which make it a good idea to run it as non-root |
| 16:50.13 | nemo | not gonna go further than that on the understanding part ⺠|
| 16:51.12 | *** join/#devuan pankerini (~pankerini@189.230.95.12) |
| 16:51.25 | nemo | muep: well given how many times the word CVE shows up in https://launchpad.net/debian/+source/xorg-server/+changelog ⦠⺠|
| 16:51.54 | muep | but this currently famous one does not look like it would be an issue unless suid is used |
| 16:52.01 | nemo | or in https://launchpad.net/debian/+source/xorg-server/2:1.19.2-1+deb9u2 at least |
| 16:52.19 | _abc_ | You can't really run any xserver as non root, it's a misnomer. Parts of it run as non root, but the core always runs as root, it interfaces with the hardware directly. |
| 16:52.46 | _abc_ | I wonder if upgrading Xorg will break anything directly and immediately. |
| 16:53.23 | muep | on my desktop it runs as muep |
| 16:53.35 | nemo | _abc_: well... the gentoo guide for running X as root solves that, it seems, by adding trusted gui users to a group with the hardware access |
| 16:53.42 | heaven | (^:^) |
| 16:53.46 | nemo | https://wiki.gentoo.org/wiki/Non_root_Xorg#Making_necessary_changes_to_system |
| 16:54.35 | _abc_ | Yes nemo but eventually it runs as root... essentially it's peeking and poking kernel memory at a level at which it can do anything once penetrated. |
| 16:54.41 | muep | I don't think it is really a misnomer. It can delegate the HW access to the kernel, which is the traditional way to do I/O in non-graphics contexts |
| 16:54.46 | nemo | _abc_: what seriously? |
| 16:54.49 | nemo | _abc_: got a source for that? |
| 16:54.57 | _abc_ | muep: do you have an accelerated server? |
| 16:55.13 | _abc_ | The docs say non accel server runs as root, accel runs as user if it can |
| 16:55.15 | nemo | _abc_: an accelerated server is still accessing video memory through a relatively restricted interface, even if it is direct access |
| 16:55.17 | _abc_ | Also are you on ascii? |
| 16:55.28 | *** join/#devuan rsx (~rsx@ppp-46-244-246-112.dynamic.mnet-online.de) |
| 16:55.33 | muep | I do not quite know what you mean by accelerated server |
| 16:55.38 | nemo | I'm kinda astonished at the X "poking at kernel memory" thing |
| 16:55.43 | muep | I have pretty good opengl support here |
| 16:55.44 | _abc_ | nemo: non vesa etc? |
| 16:55.50 | nemo | hm? |
| 16:56.00 | _abc_ | VESA |
| 16:56.06 | _abc_ | Anyway I was quoting what I read. |
| 16:56.28 | nemo | _abc_: could you link me to where you read that? |
| 16:56.49 | muep | I think the kernel does provide my processes a fairly low-level access to video hardware |
| 16:56.54 | _abc_ | I think I am quoting 20 year old stuff when it did indeed run as root and had no silicon enforced access maps. |
| 16:57.01 | nemo | ok... |
| 16:57.09 | nemo | muep: yeah but that's a bit different than kernel memory |
| 16:57.18 | nemo | muep: by that standard webgl is a major security hole (and IMO it is) |
| 16:57.24 | nemo | it's just a different level of fail is all |
| 16:57.49 | _abc_ | Iirc x86 had no silicon enforced memory access maps for processes running in kernel space. |
| 16:58.00 | _abc_ | Unlike ioperm which limits such access for ports etc. |
| 16:58.06 | nemo | and anyway, that gentoo guide seems to suggest debian could avoid the running as root if they really wanted to |
| 16:58.16 | muep | I was not talking about kernel memory at all. but I would expect that there are vulnerabilities which would allow a nominally unprivileged but still video-capably application to bypass protections of the OS |
| 16:58.20 | nemo | not super surprising since even the login manager could just be a more restricted user with the appropriate video device access |
| 16:58.26 | nemo | assuming login managers even need acceleration |
| 16:58.40 | _abc_ | kernel memory and video memory are one and the same when on a shared memory system |
| 16:58.41 | nemo | muep: yeah. there were a fair # of said problems in earlier days of webgl |
| 16:58.51 | muep | but it does not mean that it is running as root, unless you consider that in presence of bugs every unprivileged process is actually a root process |
| 16:58.57 | nemo | muep: nowdays they sanitise shaders aggressively in part due to that |
| 16:59.05 | _abc_ | Accelerated ones have separate video memory and there you can talk about not being able to poke in kernel memory with a video driver, in theory. |
| 16:59.13 | nemo | muep: in part due to just crashing graphics card due to web page being not-fun |
| 16:59.48 | _abc_ | Technically my current system is accelerated (puny, 10 year old) nvidia but uses shared memory. |
| 16:59.52 | nemo | for a long while despite CORS protection on some cards you could read arbitrary textures from webgl O_o |
| 17:00.14 | nemo | I remember when supporting hedgewars we'd sometimes get users reporting corruption in Hedgewars graphics |
| 17:00.17 | nemo | they'd send us screenshots... |
| 17:00.19 | *** join/#devuan icavot (~icavot@84.105.223.87.dynamic.jazztel.es) |
| 17:00.26 | nemo | it was parts of their UI showing up in game textures O_o |
| 17:00.37 | nemo | that is, a texture ID we thought we had legitimate was... not... |
| 17:01.30 | muep | there used to be a stage where most of our graphics drivers would barely be able to run correctly written programs |
| 17:01.34 | nemo | the problem with webgl and video cards is kind of a rerun of the problem with web fonts - hooking remote access into tools that tended to trust their inputs |
| 17:01.52 | *** join/#devuan _0bitcount (~Big_Byte@90.162.105.206) |
| 17:01.54 | nemo | and then shocker, hey, suddenly a ttf can corrupt freetype.. |
| 17:02.12 | nemo | no wonder noscript blocks them by default. and that's not even getting into the insanity with ring 0 font parsing in windows |
| 17:02.14 | *** join/#devuan antoninio (~pankerini@189.230.99.221) |
| 17:03.23 | nemo | muep: these days I think all the browsers feed the shaders into ANGLE first... |
| 17:03.34 | nemo | but, yeah, still... |
| 17:04.06 | _abc_ | Meanwhile, systemd kernel components process dhcp v6 and look at the cute bug they got just now... |
| 17:04.13 | nemo | heh |
| 17:04.39 | muep | s/kernel/network config tool/ |
| 17:04.39 | nemo | in all fairness, the dhcp bug is in a piece that's not standard deploy... yet... |
| 17:04.48 | nemo | but yeah, the code quality is apparently not great |
| 17:05.27 | nemo | _abc_: did you read this one? https://blog.erratasec.com/2018/10/systemd-is-bad-parsing-and-should-feel.html |
| 17:06.54 | muep | it has some good guidance. I often try to steer people away from the packed struct pattern |
| 17:08.11 | _abc_ | Not that Java style serialization is better in any way. Fortunately I do not deal with any of this usually. |
| 17:08.43 | nemo | muep: speaking of alignment tangentially, and debian, and, well hedgewars from above graphics chat ... |
| 17:08.55 | nemo | muep: we've been broken on 32 bit debian for a year now thanks to freepascal and SDL2 â¹ |
| 17:09.01 | nemo | took us a while to realise what was going on |
| 17:09.41 | _abc_ | nemo: heh. |
| 17:09.54 | muep | _abc_: you mean that buf[0] * 256 + buf[1] ? I think it is way better. for one, it works pretty much the same in pretty much any language that you might be using |
| 17:10.20 | _abc_ | muep: unless you're on big endian arm or mips probably |
| 17:10.28 | _abc_ | muep: Which machinesdo exist. |
| 17:10.34 | muep | _abc_: how so? |
| 17:10.53 | muep | that bit is for unserializing, not serializing |
| 17:10.54 | _abc_ | I'm guessing it would matter? |
| 17:11.02 | muep | it specifically would not matter |
| 17:11.08 | _abc_ | One hopes. |
| 17:11.23 | muep | no need to hope. because you write your code to pick the bytes always in the same order |
| 17:11.28 | _abc_ | I think the htoni() ntohi() functions were not created for nothing. |
| 17:11.39 | nemo | https://bugs.freepascal.org/view.php?id=15582 if you guys happen to use freepascal for anything for some reason ⺠|
| 17:12.05 | nemo | workaround for now will be to use the pas2c thing unc0rr wrote long ago to compile using clang instead for next debian 32 bit release - long-term we're just gonna use rust |
| 17:12.14 | muep | they are a different way to approach the problem, but like the writer of that article, I would prefer code that just naturally does the same things regardless of endianness |
| 17:12.36 | nemo | muep: well. there's also the question of why the hell are they constantly writing new code for crap that's existed for decades |
| 17:12.45 | nemo | muep: would make sense if it was implemented in, oh, node.js ð |
| 17:13.10 | nemo | they being systemd... |
| 17:13.41 | muep | this would always read the number as big-endian, regardless of HW architecture: some_number = buf[0] * 256 + buf[1] |
| 17:13.49 | _abc_ | Poettering said in his interview linked above that he will take over the world, unifiy all linuxes, and they will be all faster and better due to him |
| 17:14.34 | nemo | _abc_: heh. even if he was joking about unifying all linuxes under his control, it's probably a joke that's revealing |
| 17:14.42 | _abc_ | And that will create pax aeterna (my comment) |
| 17:14.50 | _abc_ | He was not joking. |
| 17:15.13 | _abc_ | it's not his fault, the voices in his head tell him what to do... |
| 17:15.22 | nemo | Pax Ãternum ? |
| 17:15.36 | nemo | my latin conjugation is nonexistent but I looked that one up out of curiosity |
| 17:15.56 | _abc_ | The hubris of any non institutionalized individual claiming everyone else on this planet is wrong in anno domini 2011 is absolutely remarkable from a medical point of view. |
| 17:16.30 | _abc_ | Technically I do not look these things up since my local language is Romance and Latin based. |
| 17:17.11 | *** join/#devuan IoFran (~Thunderbi@189.154.68.95) |
| 17:17.27 | _abc_ | And the modern version of that saying is pace eterna. |
| 17:18.58 | *** join/#devuan James1138 (~james1138@71-222-132-136.albq.qwest.net) |
| 17:23.01 | *** join/#devuan raoulzecat (~raoulzeca@paragram.nohost.me) |
| 17:33.22 | *** join/#devuan sacioz (~sacioz@179.191.214.232) |
| 17:38.45 | *** join/#devuan Pali (~pali@Maemo/community/contributor/Pali) |
| 17:41.16 | *** join/#devuan Akuli (~akuli@mobile-access-bceea2-116.dhcp.inet.fi) |
| 17:48.57 | *** join/#devuan Wasp (~wasp@gruenau4.informatik.hu-berlin.de) |
| 17:51.32 | ejr | so ibm is going to buy red hat - i guess that makes corporatisation of systemd even less unavoidable |
| 18:06.00 | *** join/#devuan lall- (~omg@2403:6200:88a2:600b:7dd2:f764:1c75:414d) |
| 18:08.53 | *** part/#devuan lall- (~omg@2403:6200:88a2:600b:7dd2:f764:1c75:414d) |
| 18:11.11 | *** join/#devuan IoFran (~Thunderbi@189.154.68.95) |
| 18:11.53 | *** join/#devuan pankerini (~pankerini@189.230.99.221) |
| 18:11.59 | *** join/#devuan sigjen (~sig@205.201.49.66) |
| 18:22.13 | *** join/#devuan ymasson (~ymasson@lfbn-1-8785-102.w193-250.abo.wanadoo.fr) |
| 18:31.39 | *** join/#devuan James1138 (~james1138@71-222-132-136.albq.qwest.net) |
| 18:32.25 | *** join/#devuan raoulzecat (~raoulzeca@paragram.nohost.me) |
| 18:34.44 | *** join/#devuan justinsm (~justinsm@82-69-63-196.dsl.in-addr.zen.co.uk) |
| 18:56.53 | *** join/#devuan mz` (~emerick@nebula.mz23.in) |
| 19:08.46 | *** join/#devuan AntoFox (~Thunderbi@37.162.104.144) |
| 19:16.52 | *** join/#devuan AntoFox (~Thunderbi@37.162.104.144) |
| 19:23.05 | cirdan | ejr: depends. i would hope ibm is smart enough to shitcan that trash |
| 19:32.52 | muep | to me it does not seem like RH is doing all systemd development |
| 19:35.40 | *** join/#devuan Psud0nym (~Psud0nym@c-73-184-158-200.hsd1.ga.comcast.net) |
| 19:54.00 | *** join/#devuan Psud0nym (~Thunderbi@2601:cc:8100:28b::784e) |
| 19:57.18 | *** join/#devuan IoFran (~Thunderbi@189.154.68.95) |
| 20:04.18 | *** join/#devuan raoulzecat (~raoulzeca@paragram.nohost.me) |
| 20:05.15 | *** join/#devuan justinsm (~justinsm@82-69-63-196.dsl.in-addr.zen.co.uk) |
| 20:32.26 | *** join/#devuan IoFran2 (~Thunderbi@189.154.68.95) |
| 20:39.28 | *** join/#devuan fugitive (~fugitive@159.69.149.239) |
| 20:44.07 | *** join/#devuan Psud0nym_ (~Psud0nym@c-73-184-158-200.hsd1.ga.comcast.net) |
| 21:08.30 | Digit | glimpsing at https://www.gnu.org/software/hurd/open_issues/systemd.html linked in another chan with the words "hurd is dead", i get the impression "pfff. debiand propblems." and maybe, hurd's fine devuan-wise. ? i mean, even if dormant and lacking manpower, still, nothing impeding, right? |
| 21:15.36 | *** join/#devuan targz (~Thunderbi@unaffiliated/targz) |
| 21:15.55 | *** join/#devuan marmor (~dahmar@p5DD8BBA6.dip0.t-ipconnect.de) |
| 21:17.25 | pankerini | I think GuixSD will be the first full-fledged GNU/Hurd distribution and they don't even use systemd. |
| 21:17.56 | *** join/#devuan AntoFox (~Thunderbi@37.162.104.144) |
| 21:18.40 | *** join/#devuan ktux (~ktux@176-154-223-84.abo.bbox.fr) |
| 21:23.40 | *** join/#devuan IoFran (~Thunderbi@189.154.68.95) |
| 21:24.43 | *** join/#devuan tradar (~tradar@gateway/tor-sasl/tradar) |
| 21:50.50 | *** join/#devuan raoulzecat (~raoulzeca@paragram.nohost.me) |
| 21:58.11 | *** join/#devuan AntoFox (~Thunderbi@37.162.104.144) |
| 22:06.44 | *** join/#devuan heaven (~toor@212.237.31.39) |
| 22:11.29 | Centurion_Dan | Digit: sure... we may even take up the port one of these days... |
| 22:13.01 | *** join/#devuan AntoFox (~Thunderbi@37.162.104.144) |
| 22:31.18 | *** join/#devuan IoFran (~Thunderbi@189.154.68.95) |
| 22:31.35 | *** join/#devuan alexandros_c (~alexandro@unaffiliated/alexandros-c/x-1684531) |
| 22:33.43 | *** join/#devuan Xenguy (~Xenguy@devuan/community/Xenguy) |
| 22:53.19 | *** join/#devuan AntoFox (~Thunderbi@37.162.104.144) |
| 23:21.15 | *** join/#devuan Schallaven (~Schallave@pat-199-212-66-245.airyork.yorku.ca) |
| 23:21.28 | *** join/#devuan MinceR (~mincer@unaffiliated/mincer) |
| 23:21.40 | *** part/#devuan James1138 (~james1138@71-222-132-136.albq.qwest.net) |
| 23:47.17 | *** join/#devuan Xenguy (~Xenguy@devuan/community/Xenguy) |
| 23:48.36 | *** join/#devuan IoFran (~Thunderbi@189.154.68.95) |