1425170750 Q * jrklein_ Remote host closed the connection 1425170957 J * jrklein ~cloud@proxy.dnihost.net 1425171337 Q * Ghislain Quit: Leaving. 1425171568 Q * bonbons Quit: Leaving 1425171603 Q * fstd Remote host closed the connection 1425171650 J * fstd ~fstd@xdsl-84-44-237-190.netcologne.de 1425174901 Q * jrklein Remote host closed the connection 1425175068 J * jrklein ~cloud@proxy.dnihost.net 1425184499 M * Bertl_oO off to bed now ... have a good one everyone! 1425184547 N * Bertl_oO Bertl_zZ 1425194691 Q * arekm Ping timeout: 480 seconds 1425195095 J * arekm ~arekm@ixion.pld-linux.org 1425197325 J * Ghislain ~aqueos@adsl1.aqueos.com 1425200143 J * wicope ~wicope@0001fd8a.user.oftc.net 1425202189 J * bonbons ~bonbons@2001:a18:20a:bb01:4954:3760:8507:c9f3 1425212070 N * Bertl_zZ Bertl 1425212072 M * Bertl morning folks! 1425214188 Q * Aiken Remote host closed the connection 1425214802 Q * fstd Remote host closed the connection 1425214845 J * fstd ~fstd@xdsl-87-78-14-80.netcologne.de 1425217948 Q * Defaultti Quit: Quitting. 1425218373 J * Defaultti defaultti@lakka.kapsi.fi 1425222142 J * derjohn_mobi ~aj@ip-95-223-126-17.hsi16.unitymediagroup.de 1425223892 Q * Romster Remote host closed the connection 1425223910 J * Romster ~Romster@202.168.100.149.dynamic.rev.eftel.com 1425226707 M * undefined Bertl: i'm confused by linux-vserver's capability checks 1425226723 M * undefined like for xattrs: vx_capable(CAP_SYS_ADMIN, VXC_FS_TRUSTED) 1425226764 M * undefined i think i understand the intention of vx_capable to be backwards compatible but also accommodate vservers (based on it's construction) 1425226793 M * undefined as vx_capable = capable(b) || (cap_raised(current_cap(), b) && vx_ccaps(c))) 1425226815 M * undefined where "capable(b)" is what the previous/unpatched kernel code did (ie backwards compatible) 1425226846 M * undefined and "cap_raised(current_cap(), b) && vx_ccaps(c))" is suppose to be vserver-specific functionality 1425226897 M * undefined but what breaks that is that "capable(b)" is vserver-specific when it gets down to cap_capable() with it's "vx_cap_raised(vxi, cred->cap_effective, cap)" 1425226948 M * undefined so, if i set SYS_ADMIN on a vserver, then it can set "trusted.*" xattrs even if it doesn't have FS_TRUSTED 1425227024 M * undefined or at least that's what appears to be happening 1425227066 M * undefined (the only reason that doesn't work for overlayfs is because the kernel is not setting SYS_ADMIN on a vserver's bcaps) 1425227133 M * undefined though i won't rule out that i'm confused by the number of indirections (eg macros, functions) involved in tracing through capability cod 1425227135 M * undefined code 1425227607 M * Bertl the main idea is to make a guest behave like he has the capabilities but provide a restrictive default 1425227640 M * Bertl i.e. the CAP_* is required, but not sufficient 1425227841 M * undefined Bertl: but that doesn't appear to be the case 1425227983 M * undefined based on my reading of the code and my follow-up by testing, setting SYS_ADMIN (on a vserver) appears be sufficient, and FS_TRUSTED is not necessary 1425228109 M * undefined (this is only peripherally related to overlayfs, as i had to ponder over the capability code while debugging overlayfs, but overlayfs is not required for what i'm talking about) 1425228285 M * undefined capable() -> ns_capable() -> security_capable() -> cap_capable() (in security/commoncap.c if no lsm is in use and i'm assuming correctly ;) -> vx_cap_raised() 1425228306 M * undefined but vx_cap_raised only checks for bcaps, not ccaps 1425228314 M * Bertl setting SYS_ADMIN from outside, yes? 1425228326 M * undefined yes 1425228350 M * Bertl there is a difference between adding a capability from outside to the guest or 'obtaining' it from inside 1425228374 M * Bertl of course, giving CAP_SYS_ADMIN to the guest is sufficient 1425228407 M * Bertl but if you do not give it to the guest, then a process needs to 'receive' SYS_ADMIN from inside _and_ meet the FS_TRUSTED 1425228426 M * undefined "from inside"? inside the kernel? 1425228432 M * Bertl (getting SYS_ADMIN from inside can happen e.g. through suid) 1425228439 M * undefined ah 1425228463 M * Bertl so you basically have two sets of capabilities 1425228476 M * Bertl the one set which is given from outside (i.e. through config) 1425228498 M * Bertl and the one which the guest 'thinks' he possesses from becoming root, etc 1425228524 M * undefined gotcha 1425228571 M * Bertl I know it's a little confusing especially because of the many indirections 1425228583 M * undefined *many* indirections 1425228627 M * Bertl but they are required to keep the changes a minimum 1425228637 M * Bertl and still have it work on the host as well as inside a guest 1425229070 Q * wicope Remote host closed the connection 1425229305 M * undefined so, for something like cap_raise(), should it "just work" by setting the vx_bcaps (what i believe you were previously referencing to as "given from outside") or "not work" without giving the vserver the associated ccap (in the case of overlayfs: FS_TRUSTED)? 1425229333 M * undefined "not work *by default*" 1425229334 M * Bertl yes 1425229356 M * undefined that wasn't a "yes/no" question ;) 1425229367 M * Bertl the matrix is like this: 1425229549 M * Bertl guest bcap guest ccap process cap permitted 1425229549 M * Bertl -------------------------------------------------- No No No No No No Yes No No Yes No No No Yes Yes Yes Yes XXX XXX Yes 1425229561 M * Bertl hmm, let me pastebin that 1425229582 M * undefined yeah, irc doesn't like ascii art so much 1425229583 M * undefined ;) 1425229605 M * Bertl usually I'm quite good at IRC ASCII art 1425229616 M * Bertl no idea what went wrong here 1425229621 M * Bertl http://pastebin.com/raw.php?i=uSKa1Tnv 1425229666 M * Bertl actually the last line is wrong 1425229666 M * undefined nice table 1425229723 M * Bertl http://pastebin.com/raw.php?i=DGDcymKY 1425229726 M * Bertl this one is correct 1425229744 M * undefined ah, gotcha 1425230170 Q * fstd Remote host closed the connection 1425230213 J * fstd ~fstd@xdsl-87-78-189-249.netcologne.de 1425230527 M * undefined so when the kernel does a cap_raise(), as in the case of overlayfs so as to set "trusted.*" xattrs (which could be considered good "leveraging" or bad "abusing" of user-land controllable features from kernel-space), there's no good way to make it "just work" (by default), because though the kernel, by way of cap_raise(), gives the process (within the vserver) the SYS_ADMIN capability, there's no way to safetly give it the guest ccap or bcap be 1425230606 M * Bertl correct, but a solution might be to have a special ccap like the FS_TRUSTED for overlayfs 1425230620 M * Bertl given that the checks happen inside the overlayfs code 1425231726 M * Bertl off for a nap ... bbl 1425231734 N * Bertl Bertl_zZ 1425236294 J * Aiken ~Aiken@d63f.h.jbmb.net 1425241320 J * wicope ~wicope@0001fd8a.user.oftc.net 1425243297 M * undefined Bertl_zZ: thanks for taking the time to explain some of the more difficult details of linux-vserver! 1425249431 Q * wicope Remote host closed the connection 1425250927 Q * Ghislain Quit: Leaving. 1425251426 Q * opuk Ping timeout: 480 seconds 1425251865 J * opuk ~kupo@h-1-5.a176.priv.bahnhof.se