1555028186 J * Ghislain ~Ghislain@211.ip-51-68-231.eu 1555032310 J * fstd ~fstd@xdsl-78-35-74-47.nc.de 1555032780 Q * fstd_ Ping timeout: 480 seconds 1555041019 M * Bertl_oO off to bed now ... have a good one everyone! 1555041020 N * Bertl_oO Bertl_zZ 1555055315 J * hijacker ~nikolay@149.235.255.3 1555070611 N * Bertl_zZ Bertl 1555070614 M * Bertl morning folks! 1555071398 J * _pa ~pav@141-136-185-67.dsl.iskon.hr 1555075662 M * thithib Bertl: I'm not sure I understand the purpose of the snippet of your patch in pid_revalidate() 1555075705 M * thithib I'm trying to understand why we need to #ifdef it out in CLIP OS : https://github.com/clipos-archive/src_platform_clip-patches/blob/master/1505_vserver-proc-fix.patch 1555075779 Q * Aiken Remote host closed the connection 1555076047 M * Bertl thithib: let me check ... 1555076865 M * thithib I'm trying to understand why we need to #ifdef it out in CLIP OS // if I don't, Chromium's SUID sandbox crashes because, AFAIU, a process in the new child PID namespace (not sure whether it's new PID 1) cannot access its /proc/self/fd 1555077231 M * Bertl interesting ... what error code does the kernel return on the access? 1555077372 M * thithib arf, I lost the trace, I'll reproduce and come back to you in a few minutes :) 1555077405 M * Bertl no problem, I'll take a look at the code in question in the meantime 1555079397 M * thithib Bertl: I'm not able to trace the thread that does the stat() on /proc/self/fdinfo (and then falls back to /proc/self/fd which fails too) 1555079650 Q * _pa Quit: Leaving 1555079891 Q * any0n Ping timeout: 480 seconds 1555080025 M * thithib the vxdprintk says: 338 dropped by pid_revalidate(338!=5994) 1555083241 M * Bertl hmm, what kernel version is that patch for? 1555084303 M * thithib 4.9 1555084403 M * Bertl strange ... in my 4.9 branch, the 1555084455 M * Bertl ah, nevermind, you have other patches too it seems 1555084465 M * Bertl like GRSEC 1555084480 M * thithib yes 1555084656 M * Bertl okay, could you extend the debug output to also print __task_pid_nr_ns(task, PIDTYPE_PID, task_active_pid_ns(task)) ? 1555084693 J * obeardly ~obeardly@2603:3011:1661:0:9657:a5ff:feae:1552 1555084709 M * Bertl because so far it seems to do what it is supposed to do, i.e. drop the false /proc entry 1555084735 M * thithib it's 1 1555084774 M * Bertl ah, so CHromium is running 'as init' here? 1555084830 M * thithib yes, I think the process trying to stat(/proc/self/fd) just entered a new PID namespace 1555084843 M * Bertl on the host or inside a guest? 1555084852 M * thithib inside a vserver context 1555084860 M * thithib it's the chromium SUID sandbox 1555084876 M * Bertl so you allow pid namespaces to be unshared inside the context? 1555084984 M * Bertl anyway, looks like removing the check is just papering over a different issue 1555085003 M * thithib yes, chromium has special rights on CLIP OS so it can CLONE_NEWPID without being setuid root 1555085016 M * Bertl the /proc entry which is accessed here seems to be '338' 1555085046 M * Bertl the code in question when active only drops the entry because of a mismatch 1555085080 M * Bertl (vx_map_pid() reports 5994, __task_pid_nr_ns() reports 1??) 1555085096 M * Bertl so the proc entry gets dropped and a new lookup happens 1555085101 M * thithib but isn't the mismatch « normal » when PID namespaces are used inside a guest? 1555085117 M * Bertl but I would expect that the new lookup will be '338' again 1555085166 M * Bertl only this time you get some kind of error (needs to be checked) 1555085217 M * Bertl without the d_drop() the 'wrong' entry for '338' will be accessed instead of the correct one, but Chromium just doesn't notice :) 1555087033 Q * hijacker Remote host closed the connection 1555090369 Q * dustinm` 1555090591 J * any0n ~k@4G4AAD2BD.tor-irc.dnsbl.oftc.net 1555090823 J * dustinm` ~dustinm`@68.ip-149-56-14.net 1555096027 P * DelTree_ 1555096034 J * DelTree ~deplagne@2a00:c70:1:213:246:56:18:2 1555100217 J * Aiken ~Aiken@b951.h.jbmb.net 1555100783 Q * yang Remote host closed the connection 1555100785 J * yang ~yang@yang.netrep.oftc.net 1555102032 M * Bertl off for now ... bbl 1555102034 N * Bertl Bertl_oO 1555103865 J * fstd_ ~fstd@xdsl-78-35-74-47.nc.de 1555104313 Q * fstd Ping timeout: 480 seconds