1430093877 Q * ex Server closed connection 1430093879 J * ex ~ex@valis.net.pl 1430095762 Q * hparker Ping timeout: 480 seconds 1430097051 J * hparker ~hparker@0000fb24.user.oftc.net 1430102965 Q * transacid Server closed connection 1430102985 J * transacid ~transacid@transacid.de 1430103509 Q * gnarface Server closed connection 1430103532 J * gnarface ~gnarface@108-227-52-42.lightspeed.irvnca.sbcglobal.net 1430104483 Q * PowerKe Ping timeout: 480 seconds 1430107708 J * Ghislain ~aqueos@adsl1.aqueos.com 1430110290 M * Bertl off to bed now ... have a good one everyone! 1430110305 N * Bertl Bertl_zZ 1430110495 Q * derjohn_mob Ping timeout: 480 seconds 1430111445 Q * geb Server closed connection 1430111492 J * geb ~geb@mars.gebura.eu.org 1430113673 J * derjohn_mob ~aj@tmo-113-46.customers.d1-online.com 1430114618 J * PowerKe ~tom@d54C6A573.access.telenet.be 1430117365 Q * jrklein Server closed connection 1430117402 Q * derjohn_mob Ping timeout: 480 seconds 1430118390 J * derjohn_mob ~aj@tmo-113-46.customers.d1-online.com 1430118466 J * jrklein ~cloud@proxy.dnihost.net 1430118877 Q * derjohn_mob Ping timeout: 480 seconds 1430119442 J * derjohn_mob ~aj@fw.gkh-setu.de 1430119983 Q * distemper Ping timeout: 480 seconds 1430120211 J * distemper ~user@2001:4dd0:ff00:9484:3f2f:58c8:2997:3dd2 1430120257 Q * distemper 1430120324 J * distemper ~user@2001:4dd0:ff00:9484:3f2f:58c8:2997:3dd2 1430123245 Q * kshannon Server closed connection 1430123253 J * kshannon ~kris@server.kris.shannon.id.au 1430124181 P * sid3windr In soviet russia, channel parts YOU! 1430128128 J * wicope ~wicope@0001fd8a.user.oftc.net 1430134191 Q * yang Ping timeout: 480 seconds 1430134578 J * yang yang@yang.netrep.oftc.net 1430135435 Q * jrayhawk Server closed connection 1430135437 J * jrayhawk ~jrayhawk@nursie.omgwallhack.org 1430135960 Q * fstd Remote host closed the connection 1430135973 J * fstd ~fstd@xdsl-81-173-189-159.netcologne.de 1430136443 Q * fosco Server closed connection 1430136446 J * fosco fosco@91.208.40.1 1430138393 Q * wicope Remote host closed the connection 1430138701 J * wicope ~wicope@0001fd8a.user.oftc.net 1430138875 J * X-ian ~chris@p4FFA795A.dip0.t-ipconnect.de 1430138930 M * X-ian hi. problem: I just found that I have way too many capabilities inside all my vservers 1430139009 M * X-ian inside /etc/vserver/ there are no *capabilities defined 1430139067 M * X-ian it looks like this corresponds with kernel or util-vserver version 1430139171 M * X-ian systems running some 3.18. kernel with util-vserver 0.30.216-pre3062-jessie or 0.30.216-pre3054-1~bpo70+1 (both debian) show this problem 1430139206 M * X-ian systems running 3.14 or 3.10 look ok 1430139309 M * X-ian the command which reveals the problem is: getpcaps $$ from inside a vserver 1430139364 M * X-ian a correct setup looks like "Capabilities for `13831': =ep" 1430139471 M * X-ian a broken one yields "Capabilities for `18239': = cap_chown,cap_dac_override,...,cap_block_suspend" (37 in total) 1430139510 M * X-ian any ideas, questions? 1430140963 J * Wermwud ~Wermwud@69-29-150-18.stat.centurytel.net 1430142395 M * undefined X-ian: have you tested those capabilities 1430142405 P * geb 1430142434 M * undefined if you really have CAP_SYS_TIME, then you should be able to set the time 1430142496 M * undefined and if you have CAP_MKNOD, then you should be able to create a block device, like the host's hard drive 1430142569 M * undefined the reason i ask is that i'm running 3.10.75-vs2.3.6.9-pidns-userns, 3.14.39-vs2.3.6.15-userns, & 3.18.12-vs2.3.7.4, and have the same capabilities listed on the host as in a guest 1430142603 M * undefined util-vserver 0.30.216-pre3117 1430142655 M * undefined and even though getpcaps lists those capabilites, i can't set the time or create a block device 1430142851 M * X-ian initially the following cought my attention: I upgraded a vserver instance from deb7 to deb8. on one system I got problems because pam_loginuid.so (and therefore sshd) hat insufficient permissions (CAP_SYS_RESOURCE). on some other system this problem did not occur. so I ran getpcaps ... 1430142875 Q * padde Server closed connection 1430142879 J * padde ~padde@patrick-nagel.net 1430142899 M * X-ian mknod /tmp/mynull c 1 3 1430142939 M * X-ian -> gives me an error. what the heck is going on? 1430143153 Q * Aiken Remote host closed the connection 1430143711 M * undefined interestingly, to test CAP_SYS_RESOURCE, i can increase my ulimit for open files once (1024 [default] -> 10240), but i can't increase it after that 1430143875 M * undefined that was 3.18; same behavior under 3.14 1430143990 M * undefined ha 1430143992 M * undefined no wonder 1430144004 M * undefined my hard limit is huge (1048576) 1430144123 Q * a1-away Server closed connection 1430144145 J * a1-away ~jelle@62.27.85.48 1430144235 M * undefined so though i was increasing my soft limit, it was still under my hard limit, and once i set it i was increasing my soft limit, but decreasing my hard limit 1430144275 M * undefined so, proof again, that though getpcaps lists CAP_SYS_RESOURCE, that i don't actually have it in actual use 1430144308 M * X-ian more informaton: just ran sshd with strace. There is write() call to /proc/self/loginuid. succeeds with 3.18, fails otherwise 1430144699 M * undefined nope 1430144713 M * X-ian nope what ? :-) 1430144721 M * undefined writing to /proc/PID/loginuid in a guest works for me on 3.10.75 1430144815 M * undefined but, then again, i have pidns and userns patched/enabled 1430144878 M * undefined not that pidns or userns is used for a guest 1430144998 M * X-ian ok. what whould prevent a process inside a vserver to wrote to /proc/PID/loginuid at all? 1430145013 M * undefined so even though those namespaces are enabled on my kernel, a guest doesn't use them and there should be no difference between a guest on a non-patched/non-enabled kernel and the kernel i'm running (except my kernel can run containers) 1430145130 M * undefined i can write to /proc/$$/loginuid on a non-vserver kernel as a non-privileged user 1430145284 M * X-ian I have a 3.18.8 for which this works too and a 3.10.35 which reports "Operation not permitted" 1430145616 M * undefined well, i have a 3.10.75 for which root can write to /proc/PID/loginuid, but not an unprivileged user 1430145858 M * X-ian any idea what's going on there? the internet[tm] finds several similar problems referring to /proc/ +/loginuid "Operation not permitted" - as of now I have not found the real cause of that problem 1430145959 M * undefined CONFIG_AUDIT_LOGINUID_IMMUTABLE 1430146119 M * undefined that exists in 3.10, but not 3.14 or 3.18 1430146156 M * undefined 3.13 added CAP_AUDIT_CONTROL 1430146187 Q * tokkee Server closed connection 1430146191 J * tokkee tokkee@osprey.tokkee.org 1430146994 N * Bertl_zZ Bertl 1430147000 M * Bertl morning folks! 1430148350 M * X-ian undefined: so, how would I check for capabilities inside a vserver? 1430148872 M * Bertl the same way you check on a normal host, except that you will get virtualized results 1430148961 M * X-ian hmm. i just ran "getpcaps $$" inside a vserver and got 37 caps listed, none of which I have configure AFAIK 1430149258 M * undefined X-ian: vattribute --xid XID --get 1430149334 M * undefined for my test guest (on 3.10.75) that gives "ccapabilities: ..., audit_control, ..." which means that guest can write to loginuid 1430149479 M * undefined and after running "vattribute --xid ${XID} --set --ccap ~audit_control" root, within the guest, can't "echo 0 > /proc/$$/loginuid" 1430149576 M * undefined X-ian: for clarification, vattribute is to be run on the host, not the guest 1430149634 M * X-ian now this whole thing finally begins to make sense. 1430149827 M * X-ian just one question: why on earth does getpcaps report those caps if they are not effective? 1430149896 M * Bertl because traditionally a lot fails if it doesn't see a specific cap (this might have changed over the years, but back then it was a big problem) 1430149937 M * Bertl i.e. part of the virtualization is to show caps similar to a real host, despite the fact that they are restricted 1430149973 M * X-ian ok, got it. 1430149985 M * Bertl note that it is still no problem to get the desired output by just dropping caps before/with init 1430150498 M * X-ian thanx guys 1430150501 Q * X-ian Quit: leaving 1430152051 Q * sannes Quit: Leaving. 1430155067 J * bonbons ~bonbons@2001:a18:20f:6301:ed4a:f2fe:c1ac:f895 1430155510 M * Bertl off for now ... bbl 1430155512 N * Bertl Bertl_oO 1430159003 Q * mcp Server closed connection 1430159049 J * mcp ~mcp@wolk-project.de 1430161997 Q * hparker Ping timeout: 480 seconds 1430162154 J * hparker ~hparker@0000fb24.user.oftc.net 1430165585 Q * derjohn_mob Ping timeout: 480 seconds 1430167923 J * Aiken ~Aiken@d63f.h.jbmb.net 1430168027 Q * clopez Server closed connection 1430168104 J * clopez ~tau@neutrino.es 1430168816 Q * wicope Remote host closed the connection 1430171015 Q * bonbons Quit: Leaving 1430171468 Q * Wermwud Quit: Leaving (Please imagine me slamming the door on my way out) 1430172116 J * derjohn_mob ~aj@p578b6aa1.dip0.t-ipconnect.de 1430172139 Q * Ghislain Quit: Leaving. 1430175803 Q * Defaultti Server closed connection 1430175835 J * Defaultti defaultti@lakka.kapsi.fi 1430177243 Q * Romster Server closed connection 1430177267 J * Romster ~Romster@202.168.100.149.dynamic.rev.eftel.com 1430179160 Q * fstd Remote host closed the connection 1430179171 J * fstd ~fstd@xdsl-87-78-80-224.netcologne.de