1367280212 J * ccxCZ ~ccxCZ@156.200.broadband11.iol.cz 1367280896 Q * Ghislain Quit: Leaving. 1367280898 J * Ghislain ~aqueos@adsl1.aqueos.com 1367281382 Q * Ghislain Ping timeout: 480 seconds 1367301197 M * Bertl off to bed now ... have a good one everyone! 1367301201 N * Bertl Bertl_zZ 1367304998 Q * hparker Ping timeout: 480 seconds 1367305483 J * hparker ~hparker@2001:470:1f0f:32c:beae:c5ff:fe01:b647 1367305591 J * Ghislain ~aqueos@adsl1.aqueos.com 1367314838 J * wmp ~wmp@2001:41d0:1:8616::1 1367315084 J * noob123 ~kvirc@31.15.133.178 1367315155 M * noob123 Hello! A quick question... I would like to make a simple backup of a guest system. Is it enough to backup the /etc/vserver/guest-name + /vserver/guest-data? 1367315388 M * noob123 anyone? 1367316222 M * ard to be complete: 1367316238 M * ard /etc/vserver/guest-name + /etc/vserver/guest-name/vdir/ 1367316249 M * ard wherever vdir symlinks :-) 1367316286 M * ard on restore you must make sure the directory where the symlink points to exists 1367316306 M * ard make sure you make a backup with *numeric* id's 1367316309 M * ard not with names 1367316376 M * ard eh 1367316386 M * ard numeric id's for the vdir backup 1367316393 M * ard names for the /etc/vserver backup 1367317425 Q * noob123 Ping timeout: 480 seconds 1367317445 Q * hparker Ping timeout: 480 seconds 1367317447 J * noob123 ~kvirc@31.15.133.178 1367317531 J * nkukard_ ~nkukard@197.87.148.190 1367317667 Q * nkukard Ping timeout: 480 seconds 1367317840 J * marcel__ ~marcel@pd95c7474.dip0.t-ipconnect.de 1367317870 Q * marcel__ 1367317872 J * marcel__ ~marcel@pd95c7474.dip0.t-ipconnect.de 1367319010 J * imachine ~imachine@robot.greenhost24.pl 1367320108 Q * Aiken Remote host closed the connection 1367320212 Q * ircuser-1 Ping timeout: 480 seconds 1367320817 J * ser ~ser@host1.tldp.ibiblio.org 1367321897 Q * ser Ping timeout: 480 seconds 1367321927 M * ncopa hi 1367321947 M * ncopa will there be any vserver for 3.8 or 3.9 kernels? 1367322043 Q * noob123 Quit: KVIrc 4.1.3 Equilibrium http://www.kvirc.net/ 1367322719 M * marcel__ Hi folks. I'M currently testing nginx/php-fpm(chrooted) with a vserver instance. To run external commands like sendmail php-fpm needs /proc and /dev within it's own chroot but I get: mknod: „/home/testchroot/dev/null“: Operation not permitted 1367322739 M * marcel__ Any chance on getting this to work? 1367322746 M * ptitoliv_ marcel__: hi 1367322761 M * ptitoliv_ i would say that you don't have the MKNOD capability into your vserver 1367322834 M * ptitoliv_ but you can create it outside the vserver from the host 1367322840 M * ptitoliv_ and it will be available into the vserver* 1367323276 M * marcel__ ptitoliv: thx, yes, I tried that and it seems to workefor /dev. Still ,from an administrative point of view this is somewhat difficult, as nginx/php-fpm configuration is created within the vserver instance and I would have to move some parts out. 1367323303 M * marcel__ What would I need to do to allow mknod with a vserver? Any security considerations here? 1367323320 M * ptitoliv_ well it can be 1367323327 M * ptitoliv_ if you allow mknod into the vserver 1367323337 M * ptitoliv_ the root into the vserver can create any char or block devices 1367323346 M * ptitoliv_ so he can access do the hard drives for example 1367323436 M * ptitoliv_ bbl 1367323471 M * marcel__ ptitoliv_ Hm, I tried "mknod /testchroot/dev/null c 1 3" as root with my vserver and got operation not permitted. 1367323500 M * marcel__ ptitoliv_ How do I set the MKNOD capability? 1367323646 M * marcel__ I don't quite get it from the docs 1367323661 J * ircuser-1 ~ircuser-1@35.222-62-69.ftth.swbr.surewest.net 1367323814 M * marcel__ Is it just echo MKNOD>>/etc/vserver/myvserver/bcapabilities and restart the vserver? 1367323842 M * marcel__ Will the default caps be added automatically or do I have to add them to bcapabilities file too? 1367325167 J * BenG ~bengreen@94-193-109-171.zone7.bethere.co.uk 1367327134 M * ard never done it but you should just give it the right to create certain devicenodes... 1367327155 M * ard if you are using vserver for security that is :-) 1367327260 M * ard Bertl_zZ : if I am back at work I will mail them on the list. It's just the plain old tcp_v4_rcv started from a soft_irq that eventually does a spin_lock_irqsave while that structure is already locked on the same cpu. So it is a deadlock ;-). 1367327315 M * ard today seems to be queensday, so I am not at work. 1367327398 M * fback_ marcel__: you probably want to copy /dev/null on host 1367327460 M * fback_ marcel__: giving mknod capability to guest can be dangerous, one can get to eg. raw hdd. 1367331399 Q * nkukard_ Read error: Connection timed out 1367331795 J * nkukard_ ~nkukard@197.87.148.190 1367331858 M * marcel__ fback_ thx. That is, as long as the local chroot user *can* gain root privileges within the chroot jail, correct? 1367332125 Q * imachine Ping timeout: 480 seconds 1367332371 J * imachine ~imachine@robot.greenhost24.pl 1367332557 N * Bertl_zZ Bertl 1367332562 M * Bertl morning folks! 1367332598 M * Bertl marcel__: from the security PoV, there is no need to create devices from inside a guest 1367332642 M * Bertl most cases where this comes up are badly written scripts or programs which try to create devices because they asume that the device nodes are not there 1367332687 M * Bertl when you want to 'give' access to a certain device to a specific guest, you just copy the device node into the guest's /dev 1367332736 M * Bertl it should be noted, that as fback_ said, giving block devices to a guest is usually a bad idea, because it opens a can of worms security wise 1367332798 M * Bertl /dev/null is present in a properly built guest, so no need to create it there, for a chroot inside the guest, just precreate it on the host 1367332808 Q * nkukard_ Read error: Connection timed out 1367332875 M * Bertl if you really need to create devices on the fly, you probably want to look into the device mapping features to allow certain devices while blocking other sensitive ones 1367333036 M * Bertl ncopa: probably, demand for new patches was/is? low, time is scarce 1367333127 M * ncopa Bertl, understand 1367333287 J * nkukard_ ~nkukard@197.87.148.190 1367333483 M * marcel__ Bert1 yes, correct. from an administration point of view we have all scripts to setup the php-fpm root with the vserver instance, not outside it on bare metal. So the setup scripts obviosly need to mknod 1367333546 M * marcel__ PHP within the php-fpm chroot jail needs to exec sendmail binary and here we need /dev inside the jail 1367333580 M * Bertl have you considered bind mounting (a) /dev/ into the chroot? 1367333595 M * marcel__ Although I'd be open for any other solution 1367333633 M * marcel__ Bert1 wouldn't that mean that effectivly all chroot jails share the same /dev? 1367333650 M * Bertl yes 1367333667 M * marcel__ Bert1 Hm, any security consideratiuons here? 1367333698 M * marcel__ Bert1 Actually I was told this is a bad idea 1367333708 M * Bertl in what way? 1367333734 M * Bertl I presume, your application isn't running as (guest) root, yes? 1367333749 M * Bertl so it would be simple to prevent writing to this shared /dev 1367333762 M * marcel__ Bert1 Giving it a second thought, /dev/null or /dev/random should not open any options to cross share data 1367333791 M * Bertl in turn, you drop the requirement for mknod, which is a lot more secure than being able to create arbitrary device nodes 1367333816 M * marcel__ Bert1 I try to set up a nginx/php-fpm chroot within a vrserver instance where any php-fpm chroot runs as a separate user. 1367333893 M * marcel__ Bert1 You are right, probably writing to /dev/null is required, but anything else should be readonly. None should create files within /dev/ anyway 1367333931 M * marcel__ Thx for re-hinting me this way, will give it a try! 1367334083 M * marcel__ Hm. mount: permission denied 1367334108 M * Bertl it is controlled by a bcapability 1367334118 M * Bertl s/bcap/ccap/ 1367334327 Q * nkukard_ Read error: Connection timed out 1367334646 M * marcel__ That'll be BINARY_MOUNT? 1367334694 M * marcel__ Does this cap introduce other things to consider in terms of security? 1367334731 J * nkukard_ ~nkukard@197.87.148.190 1367335007 Q * nkukard_ Max SendQ exceeded 1367335219 M * Bertl bind mounts require VXC_SECURE_MOUNT 1367335261 M * Bertl without block devices to mount inside the guest, this will be limited to (r)bind and move mounts 1367335340 J * nkukard_ ~nkukard@197.87.148.190 1367335980 M * marcel__ Bert1 thx, changed that. Anything else needed to make the devices readable? 1367336024 M * marcel__ $ mount -o bind /dev ./dev 1367336029 M * marcel__ $ ls ./dev 1367336029 M * marcel__ fd@ full log= null ptmx pts/ random shm/ tty urandom xconsole| zero 1367336039 M * marcel__ $ head -1 ./dev/urandom|hd 1367336046 M * marcel__ head: Permission denied 1367336061 M * marcel__ $ echo foo > ./dev/null 1367336066 M * marcel__ $ echo foo > ./dev/null 1367336072 M * marcel__ Permission denied 1367336472 M * Bertl most likely your mount is with nodev 1367336533 M * marcel__ Bert1 it's: mount -o bind /dev ./dev 1367336556 M * Bertl check with /proc/mounts 1367336650 M * marcel__ Bertl You are right: rw,nodev,relatime,barrier=1,data=ordered 0 0 1367337160 Q * _nono_ Quit: Leaving 1367337214 M * marcel__ What can I do? mount -o bind,dev didn't help 1367337304 M * fback_ marcel__: you have to do it in guest's context, check with FAQ (I really don't remember the line) 1367337358 M * Bertl you need to be root to do 'dev' mounts (i.e. CAP_SYS_ADMIN) and you cannot specify options on --bind mounts 1367337368 M * Bertl i.e. you need to do a remount to change options 1367337419 M * fback_ Bertl: do you have a moment? 1367337475 M * Bertl sure 1367337634 M * marcel__ Bert1 I am root 1367337741 M * marcel__ Do I need additional caps for remount? I get a permission denied again 1367337779 M * Bertl yep, remount requires VXC_SECURE_REMOUNT 1367337783 M * Ghislain hello fyi 3.4.42 seems ok with 3.4.38 patch, few hunks but compiles ok and seems tio run okay too from the little test i made 1367337925 M * fback_ Bertl: are there any changes after vs2.3.3.3 regarding setting source ip for guest traffic? 1367337983 M * Bertl which kernel version? 1367338172 M * fback_ Bertl: just a moment, I'll ask someone from the team 1367338178 N * fback_ fback 1367338329 N * ensc Guest3936 1367338339 J * ensc ~irc-ensc@p54ADFBA2.dip0.t-ipconnect.de 1367338350 M * fback Bertl: anyways, as far as I can understand them, they have two interfaces on the host, and they decided to use one of them for host traffic, and the other for guests 1367338432 J * bonbons ~bonbons@2001:a18:209:3a01:348d:3ada:bf37:ddb7 1367338476 M * marcel__ Bert1 Now I've set both VXC_SECURE_MOUNT *and* VXC_SECURE_REMOUNT in ccap file 1367338491 M * marcel__ $ mount -o bind /dev ./dev; 1367338501 M * marcel__ mount -o remount,dev /dev ./dev; 1367338517 M * marcel__ But /proc/mounts still says rw,nodev,relatime,barrier=1,data=ordered 1367338551 M * fback Bertl: so simple setup with two routing tables, first if the traffic source is from guests network, use its default 1367338612 M * fback and second, if source is host's, use host's default for communication 1367338670 M * fback Bertl: http://paste.linux-vserver.org/23811 1367338747 M * fback Bertl: they say, up until vs2.3.3.3 (still waiting for kernel version) it used to work as expected 1367338747 Q * Guest3936 Ping timeout: 480 seconds 1367338801 M * fback Bertl: and now it still works as expected for TCP, but for ICMP and UDP it seems that when checking with routing tables, source address is still undecided 1367339273 M * fback Bertl: and linux-3.3.5-vs2.3.3.3 worked as they expected 1367339294 M * Bertl and which is the non-working version? 1367339313 M * fback Bertl: linux-3.7.10-vs2.3.5.6 is not 1367339329 M * Bertl so quite a number of mainline changes inbetween 1367339335 M * fback They didn't try to bisect it to exact version that fails 1367339426 M * fback Bertl: and another question from me ;) 1367339444 M * Bertl I see a number of fixes between the involved Linux-VServer patches, but nothing which would affect this, so I presume it got broken during the port 1367339465 M * fback Bertl: is that normal that guest process can create new ip rules and inject routes into them? 1367339483 M * Bertl no 1367339568 M * fback Bertl: I know it's rather quite outdated kernel and vs (some early 3.0 kernel with some early vserver patch for it) 1367339620 M * fback 3.0.9-vs2.3.2.1 1367339654 M * Bertl if you can recreate the issue with any of the linked/maintained patches, let me know (i.e. provide a test case) 1367339752 Q * BenG Ping timeout: 480 seconds 1367339773 J * BenG ~bengreen@94-193-109-171.zone7.bethere.co.uk 1367339839 Q * BenG 1367339926 M * fback Bertl: ah, one more thing, is there some "official" way to add interfaces from non-default namespace to the guest? 1367340193 M * fback Bertl: with 3.6 and 3.7 EOL'ed, is 3.4 + vs2.3.3.9 ok to test this rule issue? 1367340718 M * Bertl yeah, 3.4+vs is supported 1367340745 M * Bertl (basically all patches linked on the wiki are, at least to some extend) 1367341720 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f 1367343022 M * fback Bertl: what about 3.5.7-vs2.3.4.3? ;-) 1367345181 M * Bertl 3.5.7-vs2.3.4.4 should be fine 1367345302 M * fback Bertl: you're pushing me for upgrade ;-)) 1367345323 M * Bertl upgrade is fine :) 1367346416 M * marcel__ Bert1, any more ideas why the remount still leads to nodev? 1367346430 M * marcel__ Bert1 and many thanks for the hints so far! 1367347256 M * Bertl you are probably still missing CAP_SYS_ADMIN, but I have to admit, that we probably need a special CCAP to make that work in a somewhat secure way 1367347273 M * Bertl if you want to test, I can whip up a patch 1367347767 Q * marcel__ Ping timeout: 480 seconds 1367349036 M * Bertl off for a nap ... bbl 1367349040 N * Bertl Bertl_zZ 1367351088 J * nlm ~nlm@host178.186-124-177.telecom.net.ar 1367351472 Q * nlm_ Ping timeout: 480 seconds 1367352228 Q * nkukard_ Read error: Connection timed out 1367360318 Q * Ghislain Quit: Leaving. 1367360320 J * Ghislain ~aqueos@adsl1.aqueos.com 1367360801 Q * Ghislain Ping timeout: 480 seconds 1367360952 Q * bonbons Quit: Leaving 1367366017 Q * Romster Ping timeout: 480 seconds