1383005574 J * kiorky ~kiorky@cryptelium.net 1383005762 Q * kiorky Remote host closed the connection 1383005949 J * kiorky ~kiorky@cryptelium.net 1383007261 Q * undefined_ Quit: be back in a few 1383007378 Q * treaki Ping timeout: 480 seconds 1383007403 J * treaki 1e11fe0f51@p4FF4BF38.dip0.t-ipconnect.de 1383007573 Q * kiorky Remote host closed the connection 1383007592 J * kiorky ~kiorky@cryptelium.net 1383007697 Q * kiorky Remote host closed the connection 1383007970 N * l0kit Guest3697 1383007976 J * l0kit ~1oxT@0001b54e.user.oftc.net 1383008146 Q * Guest3697 Ping timeout: 480 seconds 1383008668 J * kiorky ~kiorky@cryptelium.net 1383010178 M * undefined Bertl: anything you need me to do (eg secure_mount or postgres shm stack trace)? 1383010610 M * Bertl you mentioned the difference in patches, are you able to make me a diff now or point me to the location you were referring to? 1383012100 M * undefined yes 1383012244 M * undefined Bertl: i saved a tarball of my 3.10.17-vs2.3.6.6 1383012257 M * undefined Bertl: just need to extract and diff and i'll paste to the pastebin 1383012460 M * undefined Bertl: http://paste.linux-vserver.org/25884 1383012474 M * undefined Bertl: i only put mine first because i published mine first ;) 1383012608 M * undefined Bertl: when you published your patch i compared it to mine to see how close i was (because i was only trying to fix patch rejects, not understand the entirety of shm.c) 1383012672 M * undefined Bertl: but i noticed that you added the shm_unlock call though it wasn't in the 3.10.15 patch reject (and therefor i assume it wasn't in the 3.10.15 patch at all) 1383012702 M * undefined Bertl: not saying it doesn't belong, i just didn't understand why 1383012880 M * undefined Bertl: ok, now looking through my logs, i can't find a stack trace exactly like kiorky's 1383012949 M * undefined Bertl: and mine don't reference newseg(), but shm 1383013000 M * undefined Bertl: but still postgres 1383013108 M * undefined Bertl: i can paste them if beneficial 1383013153 M * Bertl actually I think that this was introduced accidentially 1383013194 M * Bertl looking through my notes, that one popped up from a reject, but checking the rejects on a new patch doesn't show it 1383013275 M * Bertl I'm now trying to find out where it actually came from 1383013297 M * undefined Bertl: it wasn't in the rejects applying patch-3.10.15-vs2.3.6.6.diff to linux-3.10.17 1383013338 M * Bertl yeah, no idea where that really came from atm 1383013349 M * Bertl but it looks wrong, I agree on that 1383013439 M * Bertl ah, I found it, that was a hunk which failed and thus the shm_unlock was not removed 1383013579 M * Bertl there should be an empty line instead of the shm_unlock(shp); there 1383013604 M * Bertl will be fixed in the next patch upload, now let's focus on the proc mount issue, yes? 1383013627 M * undefined Bertl: whatever you think is best, i'm only here to help 1383013667 M * Bertl you mentioned that it fails if you mount it anywhere else but on /proc, was that just a figure of speech or can you actually unmount/mount it there? 1383013755 M * undefined figure of speech 1383013770 M * undefined i thought about that wording after i typed it 1383013810 M * undefined i meant, "if mounted within the guest and not including the mounting of /proc that happens when you start a guest" 1383013830 M * Bertl okay, no problem, so let's do a few test printks in sensitive places, do you need/want a patch or are you confident enough to add them manually if I tell you where to add them? 1383013845 M * undefined let's try me adding them manually 1383013955 M * Bertl okay, so you are getting EPERM on the syscall 1383013960 M * undefined yep 1383014061 M * Bertl the first candidate is in line fs/namespace.c, in do_mount() 1383014080 M * Bertl in line 2302, there is a check 1383014091 M * Bertl if (!retval && !may_mount()) 1383014102 M * Bertl retval = -EPERM; 1383014117 M * Bertl right after that, before the next if (retval), add 1383014172 M * Bertl printk("retval = %d, may_mount = %d\n" retval, may_mount()); 1383014288 M * Bertl the next candidate is in do_new_mount() 1383014317 M * Bertl line 2000, after the put_filesystem() before the return -EPERM 1383014328 M * Bertl simply add 1383014370 M * Bertl printk("fs_flags = %d\n", type->fs_flags); 1383014389 M * undefined ok 1383014405 M * Bertl and finally in vfs_kern_mount() 1383014418 M * Bertl line 787 1383014428 M * Bertl before the if ((type->fs_flags & FS_BINARY_MOUNTDATA) && 1383014431 M * Bertl add 1383014476 M * Bertl printk("fs_flags = %d, vx_capable = %d\n", type->fs_flags, vx_capable(CAP_SYS_ADMIN, VXC_BINARY_MOUNT)); 1383014501 M * Bertl check if the kernel complains about wrong formats when compiling and fix them accordingly 1383014523 M * Bertl i.e. if it says expected int, got long, add an l before the d 1383014540 M * undefined string formatting, no prob 1383014709 M * undefined can you verify the patch? http://paste.linux-vserver.org/25885 1383014792 M * Bertl there is a colon missing in the last printk 1383014805 M * Bertl after the format string, I forgot to add it 1383014817 M * Bertl but when you change that, also move the entire printk up 1383014833 M * Bertl right before the if (!retval && ...) 1383014835 M * undefined comma? 1383014842 M * Bertl yep 1383014843 M * undefined between string and retval 1383014851 M * Bertl precisely 1383015123 M * undefined do want this to include your previously provided delta-secmount-feat01.diff? 1383015126 M * undefined or does it matter? 1383015171 M * Bertl doesn't really matter 1383015227 M * undefined compiling now; i'll fix the printk string formatting if it complains 1383018852 Q * ircuser-1 Quit: ircuser-1 1383019122 M * undefined Bertl: ok, "retval = -1, may_mount = 0" 1383019182 M * undefined Bertl: that's the only thing printed (in syslog) when trying to mount proc within a guest 1383019248 M * undefined Bertl: the kernel printk(s) were tripped while starting the guest 1383019326 M * undefined Bertl: but i marked (in the syslog using logger) after the guest was started and again after trying to mount proc ("mount -t proc /proc /root/tmp/proc") 1383019600 M * undefined Bertl: do we need to debug the may_mount() call stack 1383019675 M * undefined and/or investigate what the return code of security_sb_mount was 1383019896 M * undefined in this case i only know C and not the intention of the code 1383019955 M * undefined i only know how to read the code, not what values to expect in/from the code 1383020145 M * undefined nevermind, security_sb_mount does nothing but return 0 1383020412 M * Bertl so we reach do_mount, and retval is -1 1383020418 M * undefined for the record, here's what i was seeing in the stack traces related to shm: http://paste.linux-vserver.org/25888 1383020483 M * undefined all the other CPUs look like they were doing idle processing 1383020488 M * Bertl did you move the printk() in do_mount() up as I suggested? 1383020526 M * Bertl or did you leave it after the -EPERM 1383020539 M * undefined doh, missed that 1383020556 M * Bertl no problem, so it is after the -EPERM, which is fine 1383020619 M * Bertl it means that may_mount() or security_sb_mount() objected 1383020646 M * undefined yep 1383020658 M * undefined but security_sb_mount() appears to only return 0 1383020667 M * Bertl let's move it up for the next test, and add some printks for the may_mount() 1383020704 M * undefined i've gotta step away for a little bit 1383020705 M * Bertl ah, for that one, you should definitely add the patches I made 1383020729 M * Bertl okay, no problem, but I will be off to bed in an hour or two 1383020740 M * undefined so either leave me a message here or paste a patch and i'll build it tonight and test it in the morning 1383020747 M * Bertl nevertheless, we can continue tomorrow 1383020784 M * undefined yes, we can continue tomorrow; you determine the pace as i'm only here to help 1383020811 M * Bertl basically the next step is to add the patch I made and put a printk in may_mount 1383020816 M * Bertl something like: 1383020881 M * Bertl printk("namespace = %p, vx_ns_capable = %d\n", current->nsproxy->mnt_ns->user_ns, vx_ns_capable(current->nsproxy->mnt_ns->user_ns, CAP_SYS_ADMIN, VXC_SECURE_MOUNT)); 1383021212 J * ircuser-1 ~ircuser-1@35.222-62-69.ftth.swbr.surewest.net 1383021248 Q * ircuser-1 Max SendQ exceeded 1383021272 J * ircuser-1 ~ircuser-1@35.222-62-69.ftth.swbr.surewest.net 1383024135 M * undefined okay, i applied your delta-secmount-feat01.diff from yesterday (which adds back in SECURE_MOUNT and uses it in may_mount()), added printk to may_mount() before single-line return, and moved printk up to see retval from security_sb_mount(), but that should always return 0 because i've disabled all LSMs in the kernel config 1383024184 M * undefined compiling now 1383024451 M * Bertl okay, I'm still around :) 1383024749 M * undefined i'll probably go to bed before it finishes and test it first thing tomorrow morning (~7 hours later) 1383025164 M * Bertl it seems you are compiling the kernel from scratch everytime 1383025211 M * Bertl note that there is no real reason for doing that, the kernel build system is very sophisticated and will only rebuild precisely those parts which are affected by a change 1383026433 M * Bertl okay, off to bed now, have a good one everyone! 1383026447 N * Bertl Bertl_zZ 1383026556 M * undefined i've only build distro kernels (ie make deb-pkg) for so long that i don't remember how to do it any other way 1383026740 M * undefined though i think i could figure it out, but then i would probably have to copy the kernel and its modules to my virtualbox install, run depmod on the modules, create an initrd, and anything else i've forgotten 1383026799 M * undefined or just build a deb and have everything taken care for it while i preoccupy my time while doing a full (re)build ;) 1383027700 M * undefined namespace = ffffffff81634760, vx_ns_capable = 1 1383027700 M * undefined retval = 0, may_mount = 1 1383027700 M * undefined namespace = ffffffff81634760, vx_ns_capable = 1 1383027700 M * undefined fs_flags = 8, vx_capable = 0 1383032152 J * Ghislain ~aqueos@adsl1.aqueos.com 1383037201 Q * fisted Remote host closed the connection 1383037222 Q * ensc|w Remote host closed the connection 1383037227 J * fisted ~fisted@xdsl-78-35-86-54.netcologne.de 1383037233 J * ensc|w ~ensc@62.153.82.27 1383039650 J * alpha_one_x86 ~kvirc@190.186.23.212 1383039688 M * alpha_one_x86 Hello, I have: http://pastebin.com/EP4syDvx on compil for util-vserver 1383040027 M * kiorky Bertl_zZ: hello, will look if something happend during my sleep 1383040134 M * kiorky Bertl_zZ: sorry for my yesterday runaway but that major distro upgrade + cpu fan defect causing various trouble + harddrive failure t the same moment just exhausted me a bit too much, brain was not there anymore. Let me check what you guys have done during the night :p 1383042055 J * beng_ ~BenG@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net 1383042317 Q * ircuser-1 Max SendQ exceeded 1383042366 J * ircuser-1 ~ircuser-1@35.222-62-69.ftth.swbr.surewest.net 1383042415 Q * ircuser-1 Max SendQ exceeded 1383042438 J * ircuser-1 ~ircuser-1@35.222-62-69.ftth.swbr.surewest.net 1383044374 Q * ircuser-1 Ping timeout: 480 seconds 1383047174 Q * Aiken Remote host closed the connection 1383047303 J * ircuser-1 ~ircuser-1@35.222-62-69.ftth.swbr.surewest.net 1383047890 Q * ircuser-1 Max SendQ exceeded 1383051768 J * noob123 ~kvirc@31.15.133.178 1383051777 N * noob123 snixor 1383051818 M * snixor Hi! Could someone tell me what are the minimum bcapabilities needed for hosts.deny? 1383051848 M * daniel_hozac what? 1383051887 M * snixor I'd like to use hosts.deny in my vserver guest. What cminimum apabilities should I set? 1383051910 M * daniel_hozac none. it's a purely userspace concept, requiring nothing from the kernel. 1383051925 M * snixor thanks 1383052814 N * Bertl_zZ Bertl 1383052827 M * Bertl morning folks! 1383053058 M * renihs morning Bertl 1383053601 M * alpha_one_x86 Hello, somebody have any idea why I have my bug during util-vserver compiling? 1383053630 M * alpha_one_x86 http://pastebin.com/EP4syDvx 1383054220 M * Bertl probably an issue with dietlibc and your toolchain 1383054231 M * Bertl what dietlibc and gcc version do you use? 1383054384 M * snixor Is there any way to enable iptables in vserver guest? 1383054451 M * Bertl by configuring network namespaces, yes 1383054642 M * alpha_one_x86 dev-libs/dietlibc-0.33 and gcc 4.7 basicly 1383054696 M * Bertl okay, I'd try to use an older gcc/toolchain 1383054715 M * alpha_one_x86 I have try multiple version of dietlibc and utils-vserver 1383054728 M * Bertl toolchain, not dietlibc 1383054737 M * alpha_one_x86 ok, but if it's due to gcc, util-vserver update can be planned? 1383054771 M * Bertl I doubt that the problem is in util-vserver, it is more likely to be a problem of dietlibc _with_ gcc 4.7 1383054808 M * Bertl so probably your dietlibc needs to be adapted to the 'new' gcc 4.7 (but I'm guessing here right now, so please double check first) 1383056093 Q * beng_ Quit: I Leave 1383057712 M * distemper i had this problem once (dietlibc and gcc-4.7), but forgot about it... but now it seems they fixed it in cvs 1383057726 M * distemper from CHANGES file: "move stpcpy from libcompat to lib as it is now part of POSIX (Enrico Scholz)" 1383057828 M * Bertl yep, that sounds like it 1383058025 M * distemper yep, just tried again and it's compiling 1383058049 M * Bertl great! thanks for investigating 1383058486 M * kiorky Bertl: did you managed to find the fix for the sem thing ? 1383058672 M * Bertl it seems undefined found the issue and we fixed it 1383058691 M * Bertl I can upload a patch for you if you like 1383058872 M * undefined Bertl: i'm in and out today, so just let me know what you need me to do to continue debugging the secure_mount issue and i'll do it when i'm around (or if it's too much trouble/distraction, then wait 6 hours and i'll have some dedicated time) 1383059027 M * undefined kiorky, Bertl: you can probably reverse the patch i posted earlier to paste.linux-vserver.org (that addresses the single line, right, Bertl?)) 1383059028 M * kiorky Bertl: yep i would appreciate it 1383059085 M * kiorky http://paste.linux-vserver.org/25884 1383059087 M * kiorky this one ? 1383059119 M * undefined http://paste.linux-vserver.org/25884 1383059136 M * undefined kiorky: yep, but be sure to reverse (-R) it 1383059161 M * Bertl http://vserver.13thfloor.at/ExperimentalT/delta-shm-fix01.diff 1383059162 M * kiorky oh i ll cowardly apply it with my own fingers :) 1383059169 M * undefined kiorky: you need to remove, not add (as in the diff), shm_unlock() 1383059169 M * kiorky to test at first 1383059253 M * kiorky kernel compiling 1383059270 M * undefined hmmm, i can't connect to http://vserver.13thfloor.at 1383059280 M * kiorky undefined: uhm i just did 1383059284 M * kiorky (no problem here) 1383059309 M * undefined earlier i couldn't connect to http://irc.13thfloor.at 1383059312 M * undefined but now i can 1383059324 M * undefined kiorky: yeah, obviously Bertl can too ;) 1383059380 M * Bertl what does a DNS query give you? 1383059544 M * undefined vserver.13thfloor.at (209.135.140.107) 1383059558 M * Bertl okay, so that works and gives the correct IP 1383059575 M * undefined tcptraceroute shows that the broken hop appears to be at the edge of my isp 1383059596 M * Bertl so probably only a temporary problem 1383059621 M * undefined probably; don't put any effort towards it 1383060097 Q * kiorky Remote host closed the connection 1383060279 J * kiorky ~kiorky@cryptelium.net 1383060341 M * undefined it's up now 1383060525 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f 1383060839 M * kiorky Bertl: undefined a big thx, seems to be fixed ! 1383061193 M * Bertl great! thanks for testing! 1383061798 M * renihs hmm how can i give a vserver guest rights to /dev/net/tun? (tun module) 1383061944 M * Bertl NXC_TUN_CREATE 1383061960 M * renihs nvm :) 1383061963 M * renihs its in the faq 1383061976 M * renihs evil dr. google :) 1383061980 M * renihs thanks Bertl 1383061985 M * Bertl np 1383062108 M * renihs thought the faq describes a different approach, NXC_TUN_CREATE seems more easy approach 1383062176 M * daniel_hozac depends on what you want to do with it and how you want to use it. 1383062372 M * renihs well, i would prefer to give the guest the ability, even if that means some security drawbacks 1383062394 M * renihs will try both and think about practical implications 1383062421 M * renihs its funny how in how many ways one (i) can mispell "ccapabilities" 1383062753 M * renihs hmm though giving TUN_CREATE seems to be not enough alone hmm digging deeper 1383062868 M * Bertl note thtat there has been a bug where NXC_TUN_CREATE was tested against CCAPS not NCAPS 1383062898 M * renihs oh i created that in ncaps 1383062904 M * renihs should i do that in ccaps? 1383062911 M * Bertl http://vserver.13thfloor.at/ExperimentalT/delta-nxnscap-fix01.diff 1383062928 M * Bertl no, ncaps is the correct place, but your kernel might not know that :) 1383062999 M * renihs oh, evil, i am using patch-3.10.9-vs2.3.6.6.diff on 3.10.16 1383063006 M * renihs grmbl :) 1383063011 M * Bertl bug was introduced in 3.9.7 and fixed in 3.10.17+ 1383063023 M * renihs yeah, of course i am on 3.10.16 :) 1383063027 M * renihs how else could it be :) 1383063057 M * Bertl actually the latest patch doesn't include it yet, so it's not that terrible I guess :) 1383063069 M * renihs hmmz that means recompiling the kernel, my initrd, my zfs hmm, task for tomorow :) 1383063088 M * renihs oh, k, will fetch patch right away so i dont forget 1383063104 M * Bertl just put it on ccaps as ^0 for testing 1383063128 M * renihs hold on, i could put it on ^0 in ccaps now too? :p 1383063188 M * Bertl ccap bit 0 is to set the UTS name 1383063201 M * Bertl but as the bug checks against the ccaps instead of the ncaps 1383063223 M * Bertl giving that ccap will also enable the check for the TUN_CREATE :) 1383063247 M * Bertl (in your kernel, that is) 1383063248 M * renihs hmm it mutters about not permitted though :) (put it in ccabilities as ^0) 1383063269 M * Bertl maybe try SET_UTSNAME instead 1383063286 M * renihs ok....(me slightly confused) 1383063335 M * renihs still mutters :) 1383063358 M * Bertl what exactly does it mutter? 1383063376 M * renihs well, when trying to create the node it says operation not permitted 1383063389 M * renihs openvpn script claims: TUN/TAP support is not available in this kernel 1383063410 M * Bertl creating the node how? 1383063419 M * alpha_one_x86 then, I re into few day when gcc 4.6 is compiled, thanks for your tips 1383063420 M * renihs um, good point :) 1383063421 P * alpha_one_x86 No matter how dark the night, somehow the Sun rises once again 1383063430 M * renihs Bertl, from inside the guest might not be the best idea 1383063453 M * Bertl indeed :) 1383063453 M * renihs with mknod :) 1383063490 M * renihs okok, still, i will continue with that tomorow, all those namespaces already confusexd the heck out of me 1383063505 M * renihs thanks already Bertl and daniel_hozac ! 1383063558 M * Bertl you're welcome! 1383067609 J * bonbons ~bonbons@2001:a18:224:2e01:286d:ec97:2ea4:4f37 1383068108 J * ntrs ~ntrs@vault08.rosehosting.com 1383068122 J * ntrs_ ~ntrs@vault08.rosehosting.com 1383068463 Q * SteeleNivenson Ping timeout: 480 seconds 1383070815 J * SteeleNivenson ~SteeleNiv@76.89.144.193 1383074219 Q * SteeleNivenson Ping timeout: 480 seconds 1383079188 J * SteeleNivenson ~SteeleNiv@76.89.144.193 1383080401 Q * fisted Remote host closed the connection 1383080432 J * fisted ~fisted@xdsl-87-78-232-69.netcologne.de 1383081733 Q * SteeleNivenson Quit: Leaving 1383081748 J * SteeleNivenson ~SteeleNiv@76.89.144.193 1383082581 Q * bonbons Quit: Leaving 1383087143 N * l0kit Guest3781 1383087149 J * l0kit ~1oxT@0001b54e.user.oftc.net 1383087542 Q * Guest3781 Ping timeout: 480 seconds 1383089068 Q * Ghislain Quit: Leaving. 1383089069 J * Ghislain ~aqueos@adsl1.aqueos.com 1383089552 Q * Ghislain Ping timeout: 480 seconds