[00:00] tested with "chmod 000 /vservers" [00:00] hmm [00:00] it fails [00:00] Nick change: xxsearchxx -> pRiV [00:00] hmm, lets see ... [00:01] ensc: to rh9-2/ [00:01] If any questions, ask me. =) [00:01] AHTOH: which error? [00:01] if i put there file named nice with 19 inside start fails [00:01] no messages [00:01] and how to check if nproc and vm are correctly applied [00:02] pRiV: okay, will test it in a few minutes ... [00:02] ok. [00:02] I´m here about 2 hours. [00:02] Tested with [00:02] ctests tmp # uname -a [00:02] Linux ctests.pRiV.de 2.4.24-vs1.24 #5 SMP Sat Jan 24 11:24:17 CET 2004 i686 AMD Duron(tm) Processor AuthenticAMD GNU/Linux [00:02] ctests tmp # [00:02] Bertl: I'm gonna try to play with ipv6 now... should I make it against 1.2.4 of 1.3.6? [00:03] I would suggest 1.3.6 because this can also be used on 2.6 [00:03] Òkiedokie. [00:04] ensc: which util-vserver do you advice me to use with 1.3.6? 0.27.199 or anything else? [00:05] Zoiah: when you are using the experimental version, you can use 0.28.195; else, take the upcoming 1.25 [00:05] ensc: my problem was no endline, but why init inside is not niced? [00:07] AHTOH: probably just a misinterpretation of top or the fake-pid-1 code [00:07] (the real pid 1 is running with nice 0) [00:07] ensc: and how can i see that vm limit is correctly applied? that it works [00:08] ulimit -a [00:08] or testing the limits [00:08] bash-2.05b# ulimit -a [00:08] core file size (blocks, -c) 0 [00:08] data seg size (kbytes, -d) unlimited [00:08] file size (blocks, -f) unlimited [00:08] max locked memory (kbytes, -l) unlimited [00:08] max memory size (kbytes, -m) unlimited [00:08] open files (-n) 1024 [00:08] pipe size (512 bytes, -p) 8 [00:08] stack size (kbytes, -s) 8192 [00:08] cpu time (seconds, -t) unlimited [00:08] max user processes (-u) 1000 [00:08] virtual memory (kbytes, -v) unlimited [00:08] i asked vm to limit me for 32768 pages [00:08] why unlimited [00:09] pRiV: [root@XXXX root]# /tmp/rootesc [00:09] cd ..: Permission denied [00:09] Exploit seems to work. =) [00:09] but it didn't ?! [00:10] Ouch... [00:10] Bertl: should i try it on latest version? [00:11] matryoshka:/# uname -a [00:11] Linux matryoshka 2.4.24-ow1-vs1.24 #1 Thu Jan 22 10:40:51 CET 2004 i686 unknown [00:11] Bertl: it works here. [00:11] Zoiah: how do you test? [00:11] wau matryoshka? [00:11] Bertl: ls -l / [00:11] Bertl: cd / [00:11] bertl: gcc -o rootesc bla.c [00:11] Bertl: ./rootesc [00:11] hmm yup, looks good ;) [00:11] Bertl: you have to be in / of the vserver. [00:12] how does it work? [00:12] hehe [00:12] its easy [00:12] ist a ooooold [00:12] very oooold chroot bug [00:13] matters with the posix standard, [00:13] that at a chroot the current directory is not changed [00:13] ;) bad thing, works explot works fine with 2.4.24 and 1.24 vs [00:13] Where are the flowers for the finding of this create volumnarity? ;-) [00:14] -create +greate [00:14] ... [00:14] great, now we have to fix it, you get to the Hall of Fame for finding it ;) [00:14] ;) [00:14] hehe [00:14] just taking the illusion of a perfect world [00:15] hmm, pRiV the magic point is the chmod, right? [00:16] so we actually fixed that by the BARRIER flag, then? enrico what is your opinion? [00:16] yes and no [00:16] the problem is, [00:16] that if you chroot [00:17] then you are outsite of the chroot [00:17] all things then happen, [00:17] espacialy the cd .. [00:17] is worse [00:17] the kernel should not allow it [00:17] Bertl: does the barrier flag work in 2.4.x? [00:17] give me a minute it's there, just not enabled ;) [00:17] This problem is at all chroot´s [00:18] not only vserver-chroot [00:18] it is a general kernel problem. [00:18] at it is very old. =) [00:18] The posix standard forces this bad behaviour [00:18] but working [00:19] pRiV: live and learn ... [00:19] Bertl: ? [00:19] didn't know that before ... [00:20] Bertl: I thought the 000 thingy was to protect against this? [00:20] me too [00:20] well, he obviously bypasses this by changing the flags from 000 to +x [00:21] yes. =) [00:21] thats a bad thing for customer vservers ;) [00:21] it is so easy that it is too bad. =) [00:21] well, guess we have a fix in a few minutes ... [00:21] Ok, so I can write a mail to heise? [00:21] ;-) [00:22] hopfefully your mailserver gets stuck [00:22] better would be to give the providers a chance to update their systems ... [00:22] ok, If I get some flowers? [00:22] =) [00:22] sure, big blue one [00:22] which smiles like cheese ;)) [00:22] as I said, you get an entry at vserver Hall of Fame [00:22] A hint at the changes log would be ok. =) [00:23] ok, thanks. =) [00:23] thats enough. =) [00:23] changelog anyway, what's your name? [00:23] Markus Mueller from GeNUA [00:23] in germany [00:23] welcome [00:23] GeNUA is a firewall and IT-Security company [00:24] hmm, good to know ... [00:24] are you doing vserver security testing? [00:24] yes [00:24] arekm_ (misiek@ikar.t17.ds.pwr.wroc.pl) joined #vserver. [00:24] Reviewed [00:24] it [00:24] And tested thinks like this [00:24] good to have such good testers [00:24] that is great, we talked about doing such things, but never found enough resources/time to do it properly ... [00:24] hi Markus [00:24] Hi. =) [00:25] arekm (misiek@ikar.t17.ds.pwr.wroc.pl) left irc: Read error: Connection reset by peer [00:26] How many people are you? [00:26] i am just one people [00:26] lol [00:26] me too [00:26] ;-) [00:27] HAHAHAH [00:27] :) [00:27] sorry that's wrong we are three ;) [00:27] pRiV: Bertl is the main programmer/pusher/god of vserver. :) [00:27] ah, cool. So I´ve found the right person. =) [00:27] pRiV: totally. [00:28] pRiV: he generally amazes me with his skill, knowledge and sick amount of patience and enthusiasm. :) [00:28] Action: Bertl blushes ... [00:28] yeah, especialy that patience skill is good [00:29] frz (~frz@213.235.213.90) left irc: Quit: Download Gaim: http://gaim.sourceforge.net/ [00:29] lol. =) [00:31] Yes, must say that this is good work. [00:31] Question... [00:31] any practise with about 400 vservers at one time? [00:32] pRiV: there are some people using it. [00:32] pRiV: are you reviewing the userspace tools too? [00:32] I think I don´t want to start for each a own sshd... [00:32] pRiV: the limiting part is usually the kernel ... [00:32] pRiV: I don't use vservers to run an entire linux distro inside it. [00:32] 400 servers mean 'a-lot' of processes and resources ... [00:32] stable branch is insecure, but a review of alpha branch would be really nice [00:33] pRiV: I only run a statically linked apache in one, statically linked mysqld in another, etc... [00:33] I thought about a shell script like with does do a "vserver enter" [00:33] pRiV: they don't need sshd (can't even, because they don't even have /bin/sh). [00:33] frz (~frz@213.235.213.90) joined #vserver. [00:34] I think about a ssh server with does do for each user at login time a "vserver enter" [00:34] So I need only one ssh server. [00:34] pRiV: not all my vserver users have root in their vserver. [00:35] Bertl: And a feature request for you: Quota per vserver. [00:35] This would be very fine. =) [00:36] this works ;) [00:36] per partition ? [00:36] yes ;) [00:36] too bad! [00:36] =) [00:36] But I know, it´s difficult. [00:37] hmm, enrico, any tools witch support the barrier flag yet? [00:37] setattr/showattr [00:37] but in alpha only [00:37] ah okay, where is a tar I can grab? [00:37] 0.27.199 doesn support it right? [00:37] http://www-user.tu-chemnitz.de/~ensc/util-vserver/alpha/ [00:38] I am not really sure; I do not have such a highlevel changelog for alpha-tools... but when you have the '--barrier' option it should be supported [00:39] okay, then no ;) [00:40] Bertl: but .195 should compile on your machine ;) [00:41] yeah, I was surprised that the ./config didn't bitch about my compiler ;) [00:41] and even the compile complited .. great work enrico! [00:41] Bertl: but you get probably some 'no' [00:53] Bertl: lets try your proc-trigger patch [00:53] sec, still working on the chroot exploit ... [00:53] Bertl: isn't the security issue prio #1 atm? :) [00:55] Bertl: How are you going to fix this issue? [00:56] probably it's already fixed ... just fighting a little with the tools atm ... [00:56] but It's my fault, not enricos! ;) [00:56] Bertl: Shame on you then! [00:56] :) [00:57] re btw [00:57] hi virtuoso! [00:57] Daysleepers unite! [00:57] :) [00:57] JonB (~NoSuchUse@129.142.112.33.ip.tele2adsl.dk) left irc: Quit: zzzzzzzzz [00:58] enrico? [00:58] # setattr --help [00:58] Usage: setattr [-Rx] [--[~]iunlink] [--[~]admin] [--[~]watch] [--[~]hide] [--] + [00:59] # setattr --version [00:59] setattr 0.28.195 -- sets vserver specific file attributes [00:59] This program is part of util-vserver 0.28.195 [00:59] did I miss something? [00:59] is this present but no help? [00:59] ah... --barrier is not documented [01:00] (but implemented) [01:00] okay ... [01:01] hmm, enrico, how do I specify a directory? [01:02] with setattr? [01:02] yup [01:02] Isn´t it possible for me to remove this setattr? [01:02] nope [01:02] why? [01:02] I´m root, outside of the chroot. [01:02] because only the host context is allowed to modify it ;) [01:02] hm. [01:03] Bertl: try the '-d' flag [01:03] undocumented too? [01:03] oops... is not supported [01:03] or replace 'char const CMDLINE_OPTIONS_SHORT[] = "Rx";' [01:03] with ''char const CMDLINE_OPTIONS_SHORT[] = "Rx"; [01:03] would specifying name/. work? [01:03] .... "Rxd" [01:04] ... in src/setattr.c [01:06] although changing 'args->do_display_dir = false' to '... true' would be the right fix [01:06] well, what should I modify? or do you have a patch? [01:09] hehe, Rxd didn't work, but i found a quick workaround ... [01:11] pRiV: cd ..: Permission denied [01:11] Exploit seems to work. =) [01:11] but it did not work this time ;) [01:11] hehe. [01:11] what did you do? [01:12] what I do not understand now, is how do you bypass the permission check in chmod ... [01:12] pRiV: just enabled the BARRIER flag, which is in development since 1.3.5 ... [01:12] I´m outside of the chroot. [01:12] Could it be that this confuses? [01:13] no not really ... [01:13] the barrier flag... [01:13] let me try a simpler .. bash like exploit .. brb [01:13] how is the system call to remove it? [01:13] Could it be that this is also possible? :-> [01:13] let´s try. [01:14] how is the system call ? [01:14] I'll update the patch, just a minute, you can test it on your site ... [01:14] ok. [01:15] If I can chmod, why shouldn´t I can do a "unflag" ? [01:15] Do you secure both the same way? [01:15] Bertl: http://savannah.nongnu.org/cgi-bin/viewcvs/util-vserver/util-vserver/src/setattr.c.diff?r1=1.6&r2=1.7 [01:15] because the chmod is somehow allowed, don't know why yet, but the unflag would require to be in xid=0 [01:15] thanks enrico! [01:17] The barrier flag prohibites any acces to a directory? Or only chmoding? [01:19] Bertl: what was this easy oneliner of you to easily install fedora into a vserver? Something with build apt-rpm.. blah. :) [01:20] serving (~serving@213.186.188.205) joined #vserver. [01:20] okay in a vserver doing [01:20] ensc: can you answer why vm limit not works? [01:20] cd / ; chmod +x .. [01:21] is sufficient to break out .. (well you need a chroot then) [01:21] AHTOH: I probably can, but you have to wait a little until we have a good and doable solution for the chroot exploit, okay? [01:22] ensc: now checking why that chmod is possible ... [01:22] I think you´ll have a long night today. =) [01:22] pRiV: well, not longer as usual I guess ... [01:23] barrier patch, is available in a few [01:23] hehe. =) [01:24] Bertl: ok, fixing bugs is priority [01:24] tell me when you done -- hope you to fix that in devel also [01:24] it is currently 'fixed' in devel only ;) [01:25] looool [01:25] pRiV: http://vserver.13thfloor.at/Experimental/barrier-fix.diff [01:26] setting iunlink flags for /vservers would be a fast fix [01:26] int vc_set_iattr(uint32_t id, void *data) [01:26] hehe, this is the fix, right? [01:26] yep [01:26] Who maintains http://list.linux-vserver.org/? I think that because of http://64.246.21.252/robots.txt it's not archived in google, which blows little chunkies. [01:26] Martin List-Peterson IIRC [01:26] How can I reach him? [01:27] ensc: hmm, good thinking, let me try ... [01:32] Zoiah: have a look at the mailing list archives, for an email address [01:33] Bertl: then thing is, I can't search in the mailing list archives, which is what I'm trying to fix by this [01:33] s/then/the/g [01:34] deadguy (deadguy@bananajoe.big.du.se) joined #vserver. [01:36] ensc: nope, doesn't work ... [01:37] Bertl: ctx!=0 can clear immu+iunlink flags? [01:37] nope, but immu+ iunlink doesn't protect the dir ;) [01:37] well, not in the way we would like it ... [01:38] but with immu, the chmod() will fail? [01:40] yep, but adding files/dirs will fail too ... [01:40] or better, not sure if that is sufficient to do anything ... [01:40] the thing is, I can easily fix this by adding the appropriate checks in *_chmod [01:41] but I don't see why the 'usual' vfs_permission() check doesn't catch this ... [01:44] herbert, a quick question, is there a working memory limit patch for the latest vserver? [01:45] probably [01:45] hehe [01:45] :) [01:45] which memory limits? which version? [01:46] any memory limits for the latest stable [01:46] the last one i used was rik's one, many moons ago [01:46] ah for stable ... [01:46] well, without rmap no rss in stable ... [01:47] mkay [01:47] ensc: setattr does what vproc does, or? [01:47] righto, gotta go to ork, bbi10 [01:47] yep [01:48] ensc: it confuses me. :) [01:48] okay, we have a fix for that exploit ... doable on stable and devel [01:48] ensc: can you give me a small example that makes devel vserver work? (it complains about /proc now... I used it use vproc). [01:49] but I have to verify the checks, because I do not see where the chmod passes the vfs_permission/( [01:49] Zoiah: have you seen http://www.linux-vserver.org/index.php?page=alpha+util-vserver already? [01:50] ensc: ahh, no... but it doesn't explain setattr? [01:51] pRiV: http://vserver.13thfloor.at/Experimental/root-escape-fix.diff that should fix it without the barrier stuff ... [01:51] use 'setattr --watch' to set the flag which is responsible for showing entries in ctx 1 [01:51] --hide is every ctx!=0 [01:52] --iunlink should manipulate the traditional ILI flag [01:52] pRiV: by the way, if you(r company) do security auditing/etc on vserver, would it be possible to publish this somewhere? [01:52] ensc: I want to show some /proc entries to ctx!=0 [01:52] Bertl: hm... its a internal check [01:53] because we´re using some linux servers [01:53] and want to secure them [01:53] '--~hide' should do it probably; but I never tested it [01:53] hmm, okay, might become official once, and then it would be nice to be checked by ... [01:54] pRiV: I assume it's umlaut u like Mülelr, right? [01:54] yes. =) [01:54] Müller I mean [01:54] Müller [01:54] ensc: # setattr --~hide -- /proc/*info [01:54] ensc: something like that? [01:54] yep [01:54] ensc: also... if you've never tested it, how do you test vserver devel? [01:54] okay pRiV could you verify that this fixes the hole? [01:55] yes [01:55] tomorrow. =) [01:55] ensc: '/proc/cpuinfo: No such process' [01:55] I´m now going to sleep. =) [01:55] okay, np [01:55] Where can I write the result? [01:55] to my email, would be the best, I think ... [01:55] herbert@13thfloor.at [01:55] Zoiah: the kernel-interface is implemented after specification; the userspace part is tested [01:55] ok. [01:56] or the mailing list ... [01:56] But the bug is known by some other persons... [01:56] I thought so ... [01:56] could be that it is going to be public. [01:56] ensc: I understand that, but you don't use vserver yourself? [01:56] I use 1.2.24 [01:56] 1.24 [01:56] I see. [01:56] Because I just get "/proc/cpuinfo: No such process" with that line. [01:56] as I said, will fix it now, and post something on the mailing list [01:57] pRiV: thanks for reporting this .. have a good night! [02:00] ensc: the command doesn't give an error if I don't compile in the v13 API into the util-vserver. [02:04] ensc: bah, everything in the v13 api is broken? [02:04] bye all ,i goto bed [02:04] vserver-stat doesn't work with v13, setattr doesn't work with v13, etc. [02:04] Zoiah: at least the important things... ;) [02:04] AHTOH: have a good night ... [02:04] which patch are you using? [02:05] ensc: vs1.3.6 [02:05] ensc: with 0.28.195 [02:05] If I configure with "--enable-apis=legacy,compat,v11,fscompat" most of the stuff works. [02:05] Bertl released (??) patches today which fixed some problems [02:05] If I don't, most of the stuff is broken. [02:06] lilo (levin@lilo.usercloak.oftc.net) left irc: Quit: bbiab [02:08] Bertl: your patch is reversed? [02:08] Bertl: wait, I'm stupid. ;) [02:08] Doener (~doener@pD9E12286.dip.t-dialin.net) left irc: Read error: Connection reset by peer [02:10] ensc: there will be a devel release with all that fixes in a few hours ... right after the stable release [02:12] back [02:13] Bertl: your fix does not patch it. [02:13] means? [02:13] Bertl: I just applied it to my 2.4.25-rc1-vs1.3.6 [02:13] Recompiled. [02:14] Wait a minute... I should cp arch/i386/bzImage to /boot ;) [02:14] good idea ... [02:14] Ahh, no, I did do that, and then rebooted. [02:15] maybe you need to chmod 000 the /vservers once again? [02:15] Ahh, oop. [02:15] oops* [02:16] vserver:/# ./bla [02:16] cd ..: Permission denied [02:16] chmod: Operation not permitted [02:16] cd ..: Permission denied [02:16] chmod: Operation not permitted [02:16] cd ..: Permission denied [02:16] chmod: Operation not permitted [02:17] Bertl: your patch works. [02:17] thanks ;) [02:18] Did you find why the chmod() was allowed or did you just add another dirty hack? ;) [02:18] well, it is a half clean hack, and I'm not sure where it passes security yet .. [02:19] I traced the callpath all way up to vfs_permission, where the check is done correctly ... [02:19] but I guess the thing is, that the inode isn't present at the time the check is done ... [02:19] so probably that patch is the only clean way of doing it anyways ... [02:20] I see. [02:20] (now try to prove me wrong, and save me some time analyzing this ;) [02:20] Oh well, I'll just wait until your stable version is realised but now I'm going to bed. Thanks for your amazing effort! [02:21] np, have a good night! [02:21] If I would donate money through paypal it goes directly to you? [02:22] minus the amount listed on the donate page ... [02:22] about 5% or so ... [02:23] I can't really donate time or resources, so I'll just donate some money. I know it's nothing compared to all the amazing work you have done, but I can't do more. [02:25] well we are (I am) thankful for every aid, or help or just time I can spend with other people ... [02:25] I greatly appriciate all the time you (and ensc, etc.) are putting into this, it's great! [02:26] But now I'm really gone, cya. :) [02:26] cya! [02:59] hmm, it seems that everyone is asleep now ... [03:51] Doener (~doener@pD9E12286.dip.t-dialin.net) joined #vserver. [03:52] hi Doener! [03:54] hi Bertl [03:54] any vservers to fix? [03:54] it seems that the util-vserver0.28 bzip2 archive is broken... [03:54] Topic changed on #vserver by Bertl!~herbert@MAIL.13thfloor.at: http://linux-vserver.org/ || latest stable 1.25, devel 1.3.6, exp 0.06 [03:54] hmm in what way? [03:54] bunzip2: util-vserver-0.28.tar.bz2 is not a bzip2 file. [03:55] from my page? [03:55] yepp [03:55] ah yes, I see, one sec [03:56] please try again, and thanks for the report! [03:57] works [03:57] :) [03:57] perfect ... [04:09] hmmm... did you change the layout at 13thfloor? [04:10] no, not that I know of ... [04:10] why? [04:11] it looks like the wiki now ;) [04:11] ah! i guess i've hit the bug meebey also saw [04:11] hum, interesting ... [04:12] http://www.meebey.net/temp/vserver-hp-bug.png [04:12] mine looks the same [04:12] funny, actually means that your browser doesn't use the stylesheet .. for whatever reason ... [04:13] http://www.13thfloor.at/styles/13thfloor_gray.css [04:13] that is the stylesheet ;) [04:14] ah :) that js console of mozilla is really useful :) [04:14] and as far as I know, it's referenced correctly from the page ... [04:14] Error: The stylesheet http://www.13thfloor.at/styles/13thfloor_gray.css was not loaded because its MIME type, "text/plain", is not "text/css". [04:14] ahhh okay, that explains it ... [04:14] let me see if I can fix this ... [04:18] Doener: could you check again? [04:20] Bertl: what was i supposed to test with patch-2.4.25-pre8-vs1.24-q0.13pre2.diff ? [04:20] ok, firebird reports MIME type text/css [04:20] it feels teh same. [04:20] hmm, heans? [04:20] hmm, means? [04:21] Doener: does it work with mozilla or whatever you use, now? [04:21] i mean. it acts exatcly like the previous quota patch with regards to inode quotas etc. i was just wondering what you wanted me to test. [04:21] yes [04:21] Doener: thanks for spotting this, couldn't reproduce it, as my mozilla showed it fine ... [04:22] talon: it is now working correctly, right? [04:23] Bertl: you mean without adding a hash to ctx0 no. but like the previous patch adding a hash to ctx0 and enabling quotas iin ctx0 makes it work. [04:23] mozilla is behaving somewhat strange when checking for mime types of css... sometimes it complains, most of the time it doesn't... [04:23] at least that's what i experienced... [04:23] talon: should work without xid=0 hash ... so it isn't working :( [04:23] and im pretty sure the hang fix is incorporated in this one as well. [04:24] or wait, what do you mean by 'without adding a hash to ctx0' did you try context quota for example for xid=100 without adding a hash to xid=0 but _with_ adding a hash for xid=100 ? [04:25] and di this fail, or did 'just' quota on xid=0 fail without adding a xid=0 hash? [04:26] Doener: seems so, but I had no idea where to look, because it was indeterministic ... [04:26] Bertl: the link on 13thfloor for the Latest Stable Release still points to 1.24 [04:26] yes i did it withotu adding hash for ctx0 but with adding oen for xid=100 [04:26] and inode quotas failed. [04:26] on the stable release main site... [04:26] tried it with just adding hash for xid0 too fails. but if you enable quotas on xid0 it starts working. [04:27] and the intersting thign about this patch. [04:27] is is they start working without having to restart teh context. [04:27] Doener: yup missed that link, is updated ... [04:27] for inodes quotas to start working. [04:28] i can switch them on and off inwide teh running ctx100 by enabling/disabling quotas on ctx0. [04:28] okay, slow, what exactly did you do ... [04:29] hang on i will go through the steps on a cleanly booted box again. [04:30] im starting with no quota hashes on ctx0. [04:30] okay [04:31] lilo (levin@lilo.usercloak.oftc.net) joined #vserver. [04:31] and then starting a vserver at ctx100. the pre-start script will map the vroot device and add a quota hash for ctx100 [04:31] Frank00Polo (~franko@4.13.67.211) joined #vserver. [04:31] hi lilo! [04:31] hi Frank00Polo! [04:31] and the config script has the context id forced to 100. [04:32] greets... question, u guys use tun/tap for the vservers vlans? [04:32] talon: could you verify the dquot_transfer() function in fs/dquot.c IIRC [04:32] Frank00Polo: nope, no vlans in vserver yet ... [04:32] Bertl: that it exists? [04:33] nope, there should be a line at the end of that function, where inode->i_flags is combined with S_QUOTA [04:33] Frank00Polo: werent you teh guy that had problems mountign raid root devices with teh quota patch ? [04:33] talon: yes... i attribute that to a modules vs. builtin issue with raid1 and reiserfs.... [04:34] talon:... if i modularized raid1 and reiserfs, the initrd could not load the reiserfs properly, kernel panic... [04:34] talon: if i builtin the raid1 and reiserfs, it booted up fine.... [04:35] int __dquot_transfer this one or further down? [04:35] guess that one, a large function with many comments ;) [04:36] Frank: ahh yes ive done that to myself before. cnat load fs moduels form a fs you intentd to boot off of. if the kernel doesnt already know about them :) [04:36] talon... yup, chicken before egg... or was it the egg first ;) [04:37] glad it wasn't vserver related ;) [04:37] hehe... not yet anyway, ergo my being here ;) [04:38] okay, so what is your desire/wish/issue? [04:38] quick setup: vs1.24, 2.4.24 w/ quota... vserver0.29 utils.... redhat8 distrib... [04:38] tun/tap.... recommendations? [04:38] i was able to create tap0 and tap1 (using the vtun package)... [04:38] .. and bonded several vservers to these taps... [04:38] well, as I said tun/tap isn't used by vserver ... [04:38] Action: sladen ponders on why lilo is interested in vservers at 2am in the morning [04:39] its not teh very end. but there is a block at looks like: [04:39] if (transfer_to[cnt] != NODQUOT) { [04:39] dprintk("77+ increment: $%p\n", transfer_to[cnt]); [04:39] dquot_incr_inodes(transfer_to[cnt], 1); [04:39] dquot_incr_space(transfer_to[cnt], space); [04:39] inode->i_flags |= S_QUOTA; [04:39] okay, so that is in ... [04:39] hmm ... [04:39] bertl... it seems to work.... at least the aliases are created to the tap0 interfaces, and am able to ssh into them from the main box.... [04:40] hmm, yes probably because they exist 'on' the host ... [04:40] you could use dummyX for that too ... [04:40] crap... true [04:40] what is being used/recommended to use right now? [04:41] i alwyas use ext2 or ext3 for my root fs anyway. still hae to remember to compile ext3 in but its betert supported by the bootloaders on pretty much every platform. and harder to forget. [04:41] Frank00Polo: ethX or whatever you want the vservers to work on ... [04:41] esp on sparc where silo doesnt work quite like lilo does. it actually reads teh file system. [04:42] talon, okay, please continue with your test explanation ... [04:42] ok. [04:42] ah, another issue, did you add the small fix we did today? [04:42] probably not ... [04:42] considering i just woke up not likely [04:42] unlesss i patch things in my sleep. [04:43] hehe, okay, there is a line in fs/inode.c? which has to be commented out ... sec [04:44] know what, we make a complete new set of patches, so we have both the same version, is this an idea? [04:44] yeah sure. [04:44] is thre an easy way of backing out patches other than extracting a totally new krnel tree and reapplying patches in order? [04:45] yes, patch -R [04:45] but for the future, and for now, I would suggest to do the following: [04:45] starting with a clean kernel 'tar xjf linux-2.4.24.tar.bz2' [04:45] then you do 'cp -la linux-2.4.24 linux-2.4.25-rc1' [04:46] which makes a 'shallow' copy of that tree [04:46] (means there are hard links instead of copied files) [04:46] then 'cd linux-2.4.25-rc1; patch -p1 <../linux-2.4.25-rc1.diff' [04:46] patch takes care of those hardlinks ... [04:46] ahh ive just been doign regular copys of a clean 2.4.24 tree. [04:47] if your editor is configured correctly, it will also take care of this ... [04:47] unlinking and saving a copy of the edited link ... [04:47] this makes it fast and easy, and improves diff over such sources dramatically ... [04:48] i will try it your way when i get back from the store then. with your new patches. didnt know we were up to rc1 from pre8. [04:49] okay [05:13] ok im back. [05:13] okay, I have the patches ready ... almost ;) [05:13] http://vserver.13thfloor.at/Experimental/patch-2.4.25-rc1-vs1.3.6.3.diff [05:15] http://vserver.13thfloor.at/Experimental/patch-2.4.25-rc1-vs1.3.6.3-q0.13pre3.diff [05:16] is it ok to add the bme patch to that? [05:16] hmm, should, but leave it out for now ... [05:17] ok [05:18] for my tests, ext2/ext3 and v0 quota is enabled and in the kernel ... [05:18] thats my normal config. [05:18] UID24/GID24 mapping ? [05:20] hmm why the dev branch? will i need a new util-vserver package (currently usong 0.27) [05:21] yup [05:21] hmm, 0.27 might work .... [05:21] do not update until it fails ;) [05:22] quota.c:564: warning: unused variable `xid' [05:22] that is okay ... [05:23] oldconfig is still running. [05:23] now its building. [05:39] only now jutst compiled quota.c [05:40] its runnung under vmware on an old athlon box. [05:41] quotaon: Required format vfsv0 not supported by kernel. [05:41] humm ... [05:41] now I'm confused ... [05:44] Nick change: cdub -> cgone [05:44] ok booting new kernel. [05:46] erm thoguht i was. [05:47] Action: talon runs lilo and boots again [05:47] ah okay, proc security ;) [05:48] there we go now i have the new kernel booted. [05:49] Action: talon hates havign to rerun lilo. used to boot loaders that can read the filessystem. [05:51] hmm joy i cant even use vserver stop propperly because of the proc stuff. [05:52] guess we should fine a sane default really quick, right? [05:52] s/fine/find/ [05:54] yeah. i guess im going ot hafe to compile the new proc tool. [05:54] vproc [05:54] vproc-0.01 ? [05:55] or is there a newer version i need. [05:55] hmm nope, should work ... [05:58] ok once i have vproc what do i do with it? [05:58] didnt know you had a 1.25 stable released. [05:58] whast new in that? [05:59] a security vul. fixed ... [05:59] you should really subscribe to the ml ;) [05:59] would be nice if there was a changelog on the releases section. [06:00] i guess i will subscribe to teh ml later today. [06:00] well, there is a changelog, I just forgot to update it ... ;) [06:02] so what do you want me to do with vproc now that i have it compiled? im guessing for the purpose of testing teh quota patch i want to just enable everything in /proc for now. [06:02] not quite sure how to do that though. [06:02] vproc -e /proc/[a-u]* [06:04] ok got the vserver to start. [06:04] still getting vfsv0 not supported by kernel. [06:05] hmm, me too ... strange ... [06:05] ah wait ... [06:07] /tmp/vproc -e /proc/[a-u]* /proc/sys/* /proc/sys/*/* [06:07] that is the magic line ;) [06:08] well, the inode stuff works for me ... with that patch set and qhash for xid=100 only [06:09] ok it keeps trck of my inodes. [06:09] but. [06:09] it doesnt enforce the limits. [06:10] hmm, did you check for 'non' root? [06:10] or do you mean the disk limits? [06:10] i am in anon root account with inode limits. [06:10] talon@taltest2:~$ quota [06:10] Disk quotas for user talon (uid 1000): [06:10] Filesystem blocks quota limit grace files quota limit grace [06:10] /dev/hdv1 10500 0 0 1244* 4 4 [06:10] thats inside the vserver [06:11] hmm, lets verify that here ... [06:11] the fiel count will go up and down. [06:11] but it wotn prevent me form adding mroe files than my quota. [06:11] i bet though that if i add a context for ctx0 and enable quotas it will. [06:12] okay,how much? [06:12] heh, dont have much to bet. but id put at least 5 cents on it. [06:13] okay .. ;) [06:14] yep [06:14] if i enable quotas on teh vserver fs in ctx0 [06:14] inodes are enforced. [06:14] but this patch does account them propperly when thats not the case. [06:15] which didnt happen before. [06:15] well a step in the right direction ... [06:15] also this is without restarting the context. [06:15] before the last patch you sent me. you had to enable quotas onteh vserver fs and restart teh context. [06:16] for teh indoe quota to be enforced. [06:16] LALA [06:17] hm ... kestrelw? [06:18] its not really a big issue to be enablign quotas on the vserver fs inteh host context. it even sort of make sense. but if you want to continue working on it to learn why teh quota system does what it does i will keep playing with it. [06:19] well, I guess I know the quota system very intimately, and I have a good feeling what is missing right now, and yes, I'd like to fix that instead of cover it by some 'hack/workaround' 8-) [06:20] no problem. [06:20] especially before we are going to add the 'context hash for the host is added automatically' feature ... [06:21] not that that woudl do much good anyway aside form letting the quota tools enable quotas at boot without adding anything to the rc scripts. [06:22] what I do not know so well are the quota tools (userspace) do you know how to set quota for a user without eiditing the entries? [06:22] never tried doing it purely with command line options. [06:22] i jsut use edquota -u user [06:22] inside the vserver. [06:22] me too, but is kind of pointless for an automated test [06:23] i think i saw a tool in the debian packages that did that. [06:24] well, I guess the quota tools can do it too, just don't know how to use them properly ... maybe I should read the manual, after all ... [06:27] ok heres an easy way to do it i think. replace the editor env with a script that takes teh filename argument and rewrites teh file with the desired quota settings. [06:28] or at least the onyl way i can fidn based on the docs. [06:28] after you return form rewritign teh tmpfile it shoudl write the new quota. [06:28] good idea, could you hack something (script) together whcih sets 10,15 as soft/hard for inodes? [06:30] probably. im a bit rusty with things like that but it could be done. you could probably also use edquota and the ed editor with a here document. [06:33] talon (talon@host-63-149-223-100.irwinresearch.com) left irc: Quit: ircII EPIC4-1.1.12 -- Are we there yet? [06:33] talon_ (talon@host-63-149-223-100.irwinresearch.com) joined #vserver. [06:33] by the way, where do I send the 5¢ ? [06:33] Nick change: talon_ -> talon [06:34] heh i was only kidding :) paypal would eat that up anyway. [06:34] Action: talon pul out his bourne shell and ed reference [06:34] good, we'll pile it up, over the years, and I'll buy you a beer then, sounds good? [06:35] heh sounds good. [06:35] cant refuse a good beer. [06:41] bash-2.05$ touch /mnt/part1/TEST/y{1,2,3,4,5} [06:41] ide0(3,65): write failed, user file limit reached. [06:42] 0 0 0 15* 10 15 [06:43] this is what i have so far. just need to add the ed commands. [06:43] #!/bin/sh [06:43] #save current EDITOR and VISUAL environments for restoration later. [06:43] CUR_VISUAL = $VISUAL [06:43] CUR_EDITOR = $EDITOR [06:43] # set preferred editor to ed. [06:43] EDITOR=ed [06:43] VISUAL=ed [06:43] export EDITOR [06:43] export VISUAL [06:43] #execute edquota with a here document that tells ed how to edit the quota. [06:43] edquota -u $1 < ed commands here. [06:43] END [06:43] #restore env [06:43] VISUAL=$CUR_VISUAL [06:43] EDITOR=$CUR_EDITOR [06:43] export EDITOR [06:43] export VISUAL [06:45] what is that VISUAL used for? [06:46] visual is sometimes used instead of editor if the program decides your using a real terminal or are in tnteractive mode. [06:48] okay, to get the inode quota working (I'm checking for side effects atm) you have to edit two lines in dquot_transfer() [06:50] I only copy the modified versions ... [06:50] if (0 && !dqh_has_quota_enabled(dqh, cnt)) [06:50] in line 1347 (fs/dquot.c) [06:50] do you sitll need the script? i could probably make it change any quota values from the command line. afert i get a decent ed reference. (i can also use ex) [06:50] that would be really useful ... [06:51] how is that 'editor' called I guess it gets the file, right? [06:52] so probably sed would be the simplest solution ... [06:52] if (0 && transfer_from[cnt] == NODQUOT) [06:52] its called by edquota. [06:52] that is the other line (1351, fs/dquot.c) [06:52] and the here document is attached to stdin. [06:52] both have added the 0 && [06:53] everythign from < until [06:53] END [06:53] is the stdin for edquota. [06:53] yup, I got that ... [06:54] ok, so at line 1374 change #!/bin/sh [06:54] #save current EDITOR and VISUAL environments for restoration later. [06:54] CUR_VISUAL = $VISUAL [06:54] CUR_EDITOR = $EDITOR [06:54] # set preferred editor to ed. [06:54] EDITOR=ed [06:54] VISUAL=ed [06:55] export EDITOR [06:55] export VISUAL [06:55] #execute edquota with a here document that tells ed how to edit the quota. [06:55] edquota -u $1 < ed commands here. [06:55] END [06:55] #restore env [06:55] VISUAL=$CUR_VISUAL [06:55] EDITOR=$CUR_EDITOR [06:55] export EDITOR [06:55] export VISUAL [06:55] erm sorry. [06:55] -l [uid=UID|projid=PRID],bsoft=val,bhard=val,isoft=val,ihard=valwhere [06:55] what about that option to edquota? [06:56] doesnt seem to be an -l option in my edquota version. [06:56] well seems not to work in 3.09 ;) [06:57] the shell script shoudl be mostly portable anyway at least i hope so. have to try it under NetBSD sometime. [06:58] okay, could you 'adapt' /complete this so that you 'just' specify the quota values on the command line to that /bin/sh script? [06:58] anyway line 1374 [06:58] 1347, 1351 ... [06:59] hate being dislexic. [07:00] so change if (!dqh_has_quota_enabled(dqh, cnt)) to if (0 && !dqh_has_quota_enabled(dqh, cnt)) [07:00] yeah, or comment both lines out ... including the continue ... [07:02] ok both if statements are changes. [07:02] changed even. [07:02] compiling new kernel unless you have more changes. [07:02] nope, that should suffice ... [07:04] ok booting new kernel. [07:07] i lost my other irc session. [07:07] what was the vproc command i need again? [07:07] /tmp/vproc -e /proc/[a-u]* /proc/sys/* /proc/sys/*/* [07:09] yep seems to work. [07:09] going to try block limits just to be sure those still work. [07:10] yep works fine. [07:11] did we add you to the hall of fame yet? [07:11] not sure wehre is the hall of fame? [07:11] what's your name, please? [07:12] Bill Schaub [07:12] or william but i mainly go by bill. [07:12] if you prefer Bill, then Bill it is ;) [07:13] this is USA I presume, orrect? [07:13] +c [07:13] yeah. [07:14] im with Amoebasoft (www.amoebasoft.com) [07:14] you want that meantioned, I guess? [07:15] well if that is normally mentioned. [07:15] well, I wouldn't mention it, if they are some company, you do not like ;) [07:16] heh no i wouldnt say its a company i dont like. [07:17] its actually partially my company. [07:18] http://www.linux-vserver.org/index.php?page=Hall+of+Fame [07:21] heh thanks. might remind you about teh sparc64 machine later when robs gets back and puts it up. [07:21] no problem, we add that and make an entry in the 'donations' section ... [07:22] until then, you can write some smart stuff about Amoebasoft ... [07:22] like the Rose Web Services section I wrote ... [07:23] the website is going to change soon. and the AmoebaTools moved to a different section. [07:23] i dont have anything useufl to write about the apliance yet since i havent finished it yet. [07:23] well some history about the company and what they (plan to) do [07:24] what servers you use for linux-vserver such things, you can add that to the Vserver Hosting or Vserver Users section too ... [07:25] currently theres just the sun and the development vmware image. with our current distro incarnation on it. [07:26] okay, after some reviewing of those changes, the only issue I see, is that under unfortunate circumstances the quota files might get a dquot, which should not happen, but I have to verify that once again ... [07:26] aside from that, there should be no issues with those modifications ... [07:27] _shur1 (~shushushu@vserver.electronicbox.net) got netsplit. [07:27] our main product used to be add on COM objects for Sun One ASP (formerly known as chilisoft) [07:28] but after that market dried up a bit we found or main business was in consulting. and we wanted to try to get into selling hardware. [07:28] well, I've heard something about Amoebasoft, but that might be another company ... [07:29] and since we had some experience with cobalt we figured we could make an appliance that coudl fill teh void created by sun dropping the cobalt line. [07:29] ah yeah, that MOD player, that is from another Amoebasoft, right? [07:29] yeah not us. [07:29] im not even sure they are still around. [07:31] hmm, [07:31] Trinity Bays [07:32] cool name ... [07:34] http://www.amoebasoft.com/company/index.shtml thats what we currently have on our site about the company but that will change soon. [07:35] harhar ... sorry, had to use that bablefish ... to translate the page ;) [07:36] heh how badly does it mangle it? [07:36] trinity did the website. [07:38] _shur1 (~shushushu@vserver.electronicbox.net) got lost in the net-split. [07:38] _shur1 (~shushushu@vserver.electronicbox.net) joined #vserver. [07:38] and its unfotunately a bit out of date. [07:38] hmm, tell her/him it would be even better if it would be valid HTML or XHTML ;) [07:40] i did a lot of fighitng with him over that in the past. ive seen worse websites though. [07:41] he does have plans to over haul it when im finished. [07:41] well, usually non-standard pages get worse with every browser released ... [07:42] and it's not that hard to verify, just visit www.w3.org ... and activate that validator ... [07:42] okay, it's 5:40 am here and I'm going to bed now 8-) [07:43] thanks for your testing, I would appreciate a working script for the commandline quota stuff ... so if you just don't know what to do ;) .... [07:43] yeah i will try and get that working. [07:43] if you have some work to do, otoh, please do not consider coding on that ... [07:43] if all else fails i will do it in perl. [07:43] argh! [07:44] but actually i do have a few other things to finish first. [07:44] okay, have a nice one ... [07:44] Nick change: Bertl -> Bertl_zZz [07:44] good night everyone! [08:36] frz (~frz@213.235.213.90) left irc: Ping timeout: 492 seconds [08:39] kestrelw (~athomas@o2rosock0a.optus.net.au) left irc: Ping timeout: 492 seconds [08:51] talon? [09:01] kestrelw (~athomas@o2rosock0a.optus.net.au) joined #vserver. [09:05] yeah? [09:27] Frank00Polo (~franko@4.13.67.211) left irc: Quit: Frank00Polo [11:13] kestrelw (~athomas@o2rosock0a.optus.net.au) left irc: Quit: bye [12:22] frz (~frz@213.235.213.90) joined #vserver. [12:22] morning [12:23] sorry to say that but 1.2.25 vserver chroot fix doesnt fix ;/ [12:25] frz: odd, it does for me. [12:25] frz: did you chmod the /vservers back to 0? [12:25] yup [12:25] moment [12:26] i controll [12:26] frz: are you sure? Because I was fooled by that. [12:27] ;) [12:27] works [12:27] this server didnt have the 000 vserver [12:27] frz: the exploit changes it to 001, so if you apply the fix after you've run the exploit you have to change it back. [12:27] ;) thx good to know [12:28] didnt change [12:28] ? what gets changed you mean [12:29] The exploit chmods the /vserver directory. [12:30] hmm after setting /var/lib/vservers to 000 exploit didnt work and /var/lib/vservers permissions didnt change, did i miss something [12:30] Yes, you did, the permissions DID change. :) [12:31] The exploit change it to: d--------x 12 root root 4096 Feb 5 09:19 . [12:31] So you have to change it back: d--------- 12 root root 4096 Feb 5 09:19 . [12:31] You probably missed that little x. (Just like I did btw) [12:32] chmod: Operation not permitted [12:32] cd ..: Permission denied [12:32] chmod: Operation not permitted [12:32] Exploit seems to work. =) [12:32] [root@vserver:rs14 /] [12:32] [root@vserver:rs14 /]exit [12:32] root@hostE:~# ls -al /var/lib/vservers/ [12:32] total 32 [12:32] d--------- 5 root root 4096 Feb 3 15:13 . [12:32] d--------x 18 root root 4096 Feb 3 16:52 .. [12:32] you mean this x [12:35] ;/ have seen this litttle proggy changes all dit permissions up to / if it can ;) [12:35] dir [12:35] so i cant use sudo yesterday after trying out [12:37] Yup, it does that. [12:39] thx for your advise [12:39] Np. [12:42] so thanx alot and to Bertl too :) ... [12:42] frz (~frz@213.235.213.90) left #vserver. [13:17] kloo (~kloo@213-84-79-23.adsl.xs4all.nl) joined #vserver. [13:17] hi. [13:17] does the current stable vserver release have correct selection of outgoing IP address? [13:18] i still have a few ctx17a boxes, and am now running into the problem that the source address of UDP datagrams is always the vserver's first assigned address. [13:18] whereas i need it to be the address of the interface the packet is sent out on. [13:19] i.e. the regular behaviour. [13:38] strange [13:38] i though ipv4 root is set and all should work [13:47] kloo: I believe this problem was fixed in the latest vs1.2.* versios. [13:47] kloo: at the least, it's a known problem. [13:47] Action: kloo nods. [13:47] so far i've been evading it, but can't any longer. [13:47] i'm playing with vs1.25 and latest util-vserver now.. [13:48] I quite smoothly upgraded from ctx17 with vserver 0.23 to vs1.2.4 with util-vserver 0.27. [13:49] it seems to work alright as long as i don't set IPROOTDEV and do the aliases 'by hand'. [13:50] since only one of the set of IPs that i wish to assign to a vserver is actually an alias. [13:52] Is your vservername longer than hmm... 6 chars or so? [13:52] Because the aliases are build from eth0:# [13:52] noel, i already ran into that problem about a year ago. ;) [13:52] noel? [13:53] very strange. [13:53] Not strange, logical if you think about it. [13:53] i typed 'no', if i revisit that line with my 'cursor up' key it says 'no'. [13:53] but it came out 'noel'. :) [13:53] That's... odd. :) [14:10] loger joined #vserver. [14:10] like, root server on rh9, vserver fedora? [14:13] TheSeer: no, it's fine [14:13] TheSeer: i've run redhat on gentoo, debian on redhat, etc... it's fine. :) [14:14] k :) [14:14] mind nptl if you run a patched non-rh/non-fedora kernel. [14:15] i've run into trouble with semaphores not working for e.g. db4 as packaged in the distribution rpm. [14:16] easy to fix by turning nptl off in such an rpm and rebuilding, if you know this. :) [14:17] oh.. okay ;) [14:18] so using rh9 for the vserver would be better? [14:18] at least if you want to avoid that problem that is..? [14:19] noel, it's the same for both. [14:19] blah. [14:19] when i have a little peace and quiet i'm going to hunt that nick auto-completion down and shoot it. [14:19] hehe [14:19] Action: kloo apologizes. [14:20] you have to mind nptl whenever you have a distribution that uses it, but you swap out its kernel for a mainline one. [14:20] i assume that's what you'll be doing given that's what herbert's patches are for. [14:21] forget about it for now. [14:21] rm -rf /dev/brain/nptl* [14:21] when you have some concurrent code breaking, remember. :) [14:21] *g* [14:21] hehe [14:22] bbl. [14:38] miller7 (none@213.239.180.106) joined #vserver. [14:38] hi guys [14:44] hi [14:44] hey AHTOH [14:44] can i share one ip between two vservers? [14:45] I don't think so [14:45] AHTOH: yes. [14:45] Zoiah: you can? [14:45] miller7: I do. [14:45] how? [14:45] hmm [14:45] Action: miller7 thinks [14:45] miller7: just both chbinded to that IP. [14:45] miller7: you just can't run sshd both on port 22. [14:45] true [14:45] And other stuff like that. [14:46] yeah, why shouldn't it work... it's just IP share... [14:46] i can run two sshd on different ports [14:46] AHTOH: is the root person of both vservers the same one? [14:46] no [14:47] then you might have "commercial" issues :-) [14:47] like [14:47] one running a daemon on a port that normally the other should use [14:47] ie hijacking [14:47] Also, they can't both run a webserver on port 80. [14:48] if commercial -- should give diffrernt ips thats clear [14:48] but if i want to run one service in isolated context [14:48] all I'm saying is that this setup is prone to port hijacking [15:01] it's useful as a more capable chroot() jail. [15:02] the danger of port hijacking is reduced because the vservers then aren't full (useful) linux installations. [15:04] Most my vserver chroots don't even have a /bin/sh. :D [15:05] Zoiah: dont you know has Bertl fixed that security [15:05] where can i get latest patch [15:05] AHTOH: just get vs1.2.5 [15:07] and 1.3.? [15:07] where the url [15:08] is there an effort underway to clean up or replace the vserver script? [15:09] AHTOH: http://www.linux-vserver.org/ [15:09] kloo: that's what util-vserver is for. [15:09] but util-vserver comes with a vserver script. [15:09] cant find there [15:09] is ensc working to replace it? [15:10] kloo: yes [15:10] it was never pretty, and it has only been accruing fixes and extensions since. [15:10] it makes one shudder to read it. [15:10] AHTOH: "23 Jan: [VServer 1.3.6] released (Herbert). " [15:11] thats old [15:11] AHTOH: click on the vserver 1.3.6 link... [15:11] AHTOH: it's the latest development release. [15:11] i need smth from yesterday [15:11] or today [15:12] i alreday have newer 1.3.6.3 [15:12] AHTOH: then just subscribe to the mailinglist. :) [15:12] see [15:12] Zoiah, can you tell me a little about the future direction of util-vserver? or is there something on the web? [15:13] kloo: http://www.linux-vserver.org/index.php?page=alpha+util-vserver [15:13] kloo: that's all I know. [15:13] kloo: try ensc when he's awake. [15:13] thanks, and will do. [15:40] oh yes i ve found [15:40] http://vserver.13thfloor.at/Experimental/patch-2.4.25-rc1-vs1.3.6.3.diff [15:40] that is the latest for 25-rc1 [16:22] what kernel options need for vserver? [16:58] hi [16:58] one more question: [16:59] if i have a backuped server /vservers/name - dir --- how to create a config file/dir with stable tools and with alpha tools branch [17:17] serving (~serving@213.186.188.205) left irc: Ping timeout: 480 seconds [17:30] click (click@gonnamakeyou.com) left irc: Ping timeout: 480 seconds [18:16] Nick change: Bertl_zZz -> Bertl [18:16] hi folks! [18:16] hey bert [18:17] hi miller7! [18:17] I read about the security problem [18:18] good! [18:18] is it exploitable by normal user? [18:18] or just by vserver root? [18:18] just vserver root [18:18] ok [18:18] hi, Bertl. [18:18] how easy is it to exploit? [18:18] hi kloo! [18:19] meaning, how soon I should patch my box? [18:19] miller7: 'cd /; chmod +x ..' [18:19] ah ok :) [18:20] Bertl, are there plans to select source address for packets sent from an IN_ANY-bound UDP sockets, using the routing table? [18:20] yup, are you interested in testing such stuff? [18:20] if i'm not mistaken, the vserver's primary IP address is always selected. [18:21] yep! [18:21] hi Bertl! [18:21] i need to have certain packets take a VPN route. [18:21] is http://vserver.13thfloor.at/Experimental/patch-2.4.25-rc1-vs1.3.6.3.diff -- with fixed security bug? [18:22] nope, not yet, but 1.3.7 will [18:22] currently, the source address is not set to the VPN interface's address and reply packets come back unencrypted. [18:22] when could i be testing such stuff Bertl? :) [18:23] well, the kernel part is easy, you'd have to adapt the userspace tools a little ... [18:23] do you think you can handle that? [18:24] umm.. i can write code and fiddle, if that's what you mean. :) [18:24] i'm not conversant with vserver details. [18:24] yeah, well, we need a new ipv4root syscall (let's say a modified version) [18:24] basically this is done with a 'struct' in util-vserver [18:24] oh, you want the userland to hand the kernel the relevant data? [18:25] so it should be sufficient to modify this struct ... [18:25] i considered that the logic in the kernel might not be very easy, because both the routing table and the ipv4root info need to be consulted. [18:25] nope, doesn't work, that was already tried ... [18:26] could you sketch the proposed solution for me? [18:26] problem is, you never know 'what' source address to use [18:26] (or is it documented somewhere?) [18:27] well, maybe we are talking about different aims ... but [18:27] the basic issue usually is, you have N ips [18:27] and either one of them should be the one which is used for 'outbound' stuff [18:28] [HvD] (~guess@62.99.252.14) joined #vserver. [18:28] or you have different routes to different networks with different default gateways, in which case you want the 'right' outbound src, right? [18:28] yes. [18:28] a packet gets sent out on an interface. [18:29] if a vserver has multiple addresses for this interface (aliases), it needs to know which one to pick. [18:29] the second case is already done properly, if you configureyour routing tables as required ... [18:29] if there is only one address for an interface, it needs to pick that one. [18:30] how is the second case handled properly? [18:30] so for incoming traffic, the logic always selects the same src as the connection was done, and for outbound, the routing tables are consulted ... [18:30] right. [18:31] I'll give you an example for the second case ... [18:31] but the routing table alone is not enough when faced with multiple aliases on the same interface? [18:31] hmm, why not? [18:31] which alias should it select as outgoing address? [18:31] Bertl: i am using 25-rc1 with 0.28 enricos tools -- all seem to work... [18:31] sounds good ... [18:32] AHTOH: that is development, right? [18:32] yea [18:32] ? [18:32] 25-rc1 with 1.3.6.3 [18:32] just reminds me that I have to add the 'fix' [18:32] i am launching that for real servers [18:33] by the way, yesterday we did a 'final' fix for the quota stuff ... [18:33] so? [18:33] you might be interested if you do not already use it ;) [18:33] quota should work in latest devel? [18:34] yes, but there where some issues with nox existing quota hashes ... [18:34] with lstest 0.28.195 utils? [18:34] that was resolved early in the morning ;) [18:34] ok when you will do the 1.3.7 i ll test it and then will try quota [18:35] good, should be this night ... [18:35] kloo: okay ad multiple aliases on one interface [18:35] consider two networks, 192.168.0.0/24 and 10.0.0.0/24 [18:35] your host has 192.168.0.100 and 10.0.0.100 on that networks [18:36] your default route goes to 192.168.0.1 and 10.0.0.1 respectively [18:37] so you have to configure two routing tables both based on the src ip being in the 192.168.0.0/24 or 10.0.0.0/24 range respectively [18:37] is this understood? [18:37] with iproute you mean? [18:37] iproute2 [18:38] so now there are 3 cases, all handled differently [18:38] but this is to work around the lack of normal routing logic with vserver, right? [18:38] nope [18:38] that's without vserver ;) [18:39] or did you ever make two default gateways succeed without separate routing tables? [18:39] i guess "default route" is the operative term here. [18:39] you can't configure a 'default' route to two different gateways? [18:40] my problem is in assigning addresses from different interfaces to the same vserver. [18:40] okay, show me how you'd configure the given setup on your non-vserver linux box? [18:40] i have an eth0:vserver, and a tun0. [18:40] regardless of the number of interface ... [18:41] when a UDP datagram is sent on an unbound (INADDR_ANY) socket to tun0's peer address, it gets eth0:vserver's address as its source. [18:42] it should have tun0's address as its source, because it is sent out on tun0. [18:43] you did check that on a non-vserver machine, that this behaviour is there? [18:43] AHTOH (~Anton@212.1.230.115) left irc: Read error: No route to host [18:43] this is normal routing logic on any Unix-alike. [18:44] linux routing logic is not normal routing logic ;) [18:44] AHTOH (~Anton@212.1.230.115) joined #vserver. [18:44] linux is not that broken. ;) [18:44] but it reserves the right to use 'any' host address for outbound connections [18:45] unless you specify otherwise ... which requires routing tables ... [18:45] yes, it is specified by the route taken. [18:46] the route selects the outgoing interface, and that interface's address is used as the source address for unbound sockets. [18:46] okay, let's do some testing, you've got a box to test? [18:47] this is a bit difficult for vserver, as it can't do it like that. [18:47] because of the address restrictions in ipv4root. [18:47] why not, vserver code also uses the routing tables ;) [18:48] but the (primary) address of an interface is not necessarily assigned to the vserver. [18:48] you 'just' have to handle the case that the 'desired' source address isn't available ;) [18:48] it has to cross-reference with ipv4root. [18:48] then which address is selected? [18:49] if linux has eth0 and eth0:a, it takes eth0. [18:49] but if you have eth0:a and eth0:b, which is primary? [18:49] that is exactly what I thought you wanted to adapt ... [18:49] which is what I plan to add (a default source ip) [18:50] currently it's the first ip specified for that vserver ... [18:50] right. [18:50] but there can be no global default source ip, only a default source ip per interface. [18:51] the interface follows from the route. [18:52] sladen (paul@starsky.19inch.net) left irc: Ping timeout: 501 seconds [18:55] hmm, well, that is a point ... [18:56] also as far as i can tell it works properly for TCP. [18:56] but otoh, I do not see any code which is based on the interface or primary address of the interface in the kernel ... [18:56] click (click@gonnamakeyou.com) joined #vserver. [18:57] ufff at last -- all my linuxes at home run 2.6.2 now [18:57] there is of course a difference, because for a TCP socket the source address is filled in on connect(). [18:57] okay, look, we have to make a simple, reproducible test for that, which I can do with QEMU for example ... if that showes erroneous behaviour, I can fix that [18:57] for an unbound UDP socket doing sendto() or what-have-you, it can vary. [18:58] and incorrect behaviour means behaviour different from an unpatched kernel ;) [18:58] of course. [18:58] i haven't worked with qemu before, i'll have a look at it. [18:59] you mean for me to make a linux image containing a script and/or instructions to show this issue? [19:00] you can get some stuff from me, but we can also work on a script together ... [19:02] for starters i can hack up a perl script to send some UDP. [19:02] it should be easy from there. [19:03] i'll get back to you when i have that done, okay? [19:03] what about hping2? [19:03] Action: kloo knows hping2 not. [19:03] check it out, should do what we need ;) [19:03] oh that looks good. [19:03] sladen (paul@starsky.19inch.net) joined #vserver. [19:04] Action: kloo emerges hping. :) [19:04] i'll be back in a while. [19:04] okay, let me know ... [19:04] james (~james@h24-71-63-164.ok.shawcable.net) joined #vserver. [19:04] possible caveat: qemu only does one interface atm, either we have to hack it up, or use ssh/pppd to get a second ... [19:05] hi james! [19:05] mornin [19:05] there was a god called james ... [19:09] serving (~serving@213.186.188.205) joined #vserver. [19:09] hi serving! [19:34] are you still here Bertl? [19:35] i neglected other duties and therefore now have proof of my allegation. :) [19:35] sec, phone [19:44] okay [19:44] let's hear! [19:44] http://press.alt-f4.org/udptest.c [19:44] hping works correctly, because it uses connected UDP sockets. [19:44] that there test bitty uses an unbound socket and sendto(), which goes awry. [19:45] hmm, just a short question, what does Alt-F4 do? [19:45] i hope my testing instructions are clear, i wrote them at high speed. [19:46] in some circumstances it frees virtual desktop real estate. [19:47] a real-world program affected by this is Amanda, the backup software. [19:47] I'm still trying to comprehend what you wrote, which is not your fault ;) [19:49] hmm, okay, I guess I got it now ... let's have a look at the kernel ... [19:53] i'll be happy to hear of the fruits of your investigation Bertl. [19:53] Action: kloo will return in due course. [19:53] well, obviously this calls sendto() [19:53] ah. [19:53] yep! :) [19:53] which calls sock_sendmsg() [19:54] which calls sock->ops->sendmsg() [19:54] ops probably being a struct of protocol-specific functions.. [19:54] which should be udp_sendmsg [19:54] which.. doesn't do what it should? :) [19:55] kernel isn't htat simple ;) [19:55] i know, or i would have presented you with a fix. [19:55] Action: kloo has to run now. [19:55] okay, run! [19:55] if you can fix it, that'd be great. [19:55] let's see ... [19:55] i may have to buy you two pieces of cake if we ever run into eachother. [19:56] see you! [19:56] cu2 [20:10] noel- (~noel@pD9FFA44F.dip.t-dialin.net) joined #vserver. [20:16] noel-: ? [20:16] Nesh (~dmistry@su-nat.datapipe.net) joined #vserver. [20:16] wheee [20:16] hi dinesh! [20:16] Bert! [20:16] how are you [20:16] vserver exploits are good, I see all the people here ;) [20:17] lol [20:17] thanks fine .. [20:17] how are you? [20:17] im good been busy [20:18] noel (~noel@pD952CD53.dip.t-dialin.net) left irc: Ping timeout: 504 seconds [20:19] so what brings you here? [20:20] looking for a login for the php based vserver admin tool [20:20] for the demo site [20:20] hmm, isn't there a demo account around? [20:21] Please note: You have to order a login from IRC channel or via email! - System monitored! [20:21] ah, okay, then probably that is the right place ... [20:21] I'm curious though, how you will do that ;) [20:21] not sure what channel [20:22] server: irc.bongster.de channel: #pbvsc [20:22] ask Shade [20:22] ah thx [20:22] hmm, ... interesting ... [20:23] hehe [20:23] Bertl (~herbert@MAIL.13thfloor.at) left irc: Quit: Changing server [20:23] lol [20:23] hmm, that's interesting also.... [20:24] what is? [20:25] was just reading the ml... about the exploit fix breaking debian... [20:28] Bertl (~herbert@MAIL.13thfloor.at) joined #vserver. [20:28] upsi ... [20:29] ah [20:29] Doener: where was that channel again? [20:29] i am looking for a demo login to the site [20:29] yes [20:29] im here but currently we dont create new logins [20:29] we stand short before release 1.0 [20:29] give us few days [20:29] and you can download it from our website [20:29] oh ok so no more demo's [20:30] save you time :) [20:30] thanks ;) [20:32] Bertl: on irc.bongster.de [20:33] ok... i should read everything before starting to type... [20:33] np [20:56] Bertl: the check for '..' will not work for fchmod() [20:56] hmm, right ... well I guess we have to use the BARRIER then [21:17] ensc: shouldn't be too much hazzle to add the BARRIER flag to the stable kernel, with the same interface as the /procfs in that kernel uses (ioctl) could you adapt the tools to use that? [21:18] will be a rewrite; backport would be too difficultly [21:18] well, guess the flag could be set with the vproc tool or something as simple as that (maybe vbarrier?) [21:19] I'm more concerned about the scripts ... [21:20] why? 'vrpm' is the only one which will not work anymore; but is anybody using it? [21:21] what do I know about that? ;) [21:22] what about alexeys comment, I mean what is the status of private namespaces? [21:22] you said it's not the vserver way ;) [21:22] Action: miller7 is teasing bert [21:23] Bertl: as I wrote, I do not get the mount() to work [21:23] miller7: hmm, never said that, did I? [21:23] I didn't hear ya for sure! :) [21:24] ensc: hmm, did you bug Al Viro about that? [21:24] I mean it's supposed to work, and IIRC Eric reported that latest busy box does it ;) [21:25] no; questions to lkml are having not very much success and Al Viro does not answer [21:25] could you try the cvs/devel busybox, and see if that works/is true? [21:26] he said something about actually using it somewhere, IIRC [21:26] what would busybox change? I am using native mount(2) syscall [21:27] I don't know, maybe it does something different ... [21:27] was just an idea, if you say, nope, that won't work either, I believe you ;) [21:31] ensc: maybe we should 'adapt' the way alex does this, by creating the namespace beforehand, and migrating the process into it ... [21:32] we would have to migrate processes on ctx switch anyway ... [21:32] yes, ctx should get namespace of the creator-process [21:33] so we could 'create' the namespace like a recbind mount would do it and assign it to the context [21:34] every process will then get migrated into that namespace, including the creator-process, would that be sufficient [21:34] ? [21:36] the namespace and mounting are independent [21:38] e.g. create namespace -> mount filesystems -> chcontext ... /sbin/init [21:39] okay, what is your preference, BARRIER flag in stable or CLONE solution ? [21:39] BARRIER [21:39] okay, then we go for that in stable, and think about the other for devel, right? [21:39] clone does not work yet and needs more chages to userspace tools [21:39] yep [21:39] is my preference too .. [21:42] ensc: by the way, is fchmod() exploitable? [21:43] probably [21:43] I'm not sure that can be used to chmod '..' ? [21:43] especially as you can open '..' ;) [21:43] s/can/can't/ [21:47] right; when you can not get an fd on '..' it will fail [21:52] hmm, enrico, guess I have to apologize ... the exploit can be fixed by 'just' adding immutable flag to the /vservers dir :( [21:56] but that has the 'unwanted' sideeffect of not being able to create/destroy vservers ... [22:01] so this isn't a real fix ... but we might either use the iunlink flag to create a special mark, avoiding the barrier flag, or add the barrier stuff ... [22:01] ensc: do any of your tools use iunlink on directories? [22:02] setattr [22:03] hehe, well except for that ;) [22:04] what I meant is, for unification and such, do you create IUNLINK dirs? [22:04] no, dirs are ignored there [22:04] and would it be any issue if dirs with iunlink, magically do not allow chmod? [22:05] Filther (Filther@nilus-1858.adsl.datanet.hu) joined #vserver. [22:05] hi [22:05] hi! [22:05] could you help? :) [22:05] I'm trying to apply the security fix patch [22:05] ensc: and one step further, if dirs, with IUNLINK and 000 are barriers [22:05] (1.25) [22:06] and I get this: [22:06] Filther: best wait a few minutes we are woking on a better fix ... [22:06] [root@vpserver linux-2.4.24]# cat ../patch-2.4.24-vs1.25.diff | patch -p1 [22:06] patching file Documentation/Configure.help [22:06] Reversed (or previously applied) patch detected! Assume -R? [n] [22:06] hmm [22:06] okay [22:06] probably you are using vs1.25 which includes this fix ;) [22:06] what should I answer to this, when the new patch will be out? [22:06] no, I'm using 1.24 [22:07] hmm, did I manage to do a bad patch?, let me check ... [22:09] please verify the md5sum: http://www.13thfloor.at/vserver/s_release/v1.25/patch-2.4.24-vs1.25.diff.md5 [22:09] tell me how [22:09] ;) [22:09] that patch applies cleanly here against 2.4.24 [22:10] Filther: you do md5sum patch-2.4.24-vs1.25.diff [22:10] and compare that to that url ... [22:11] it's the same [22:11] is this just the patch or is it a total patch against 2.4.24? [22:11] total patch agains 2.4.24 [22:12] Filther: are you sure you're patching on a clean kernel? [22:12] okay, let me verify that too ... [22:12] I've patched the kernel before, with the vs1.24 patch [22:13] http://www.13thfloor.at/vserver/s_release/delta/delta-2.4.24-vs1.24-vs1.25.diff [22:13] if I understand well, you should just patch a clean kernel (just keep the .config file!) [22:13] Filther: that is if you want to 'upgrade' [22:13] but better, please do what bert says [22:13] alright [22:13] no problem, then [22:13] ;> [22:13] but as I said, we are working on a better solution ... [22:14] ensc: okay, so iunlink, 000 for the barrier dir should work, right? [22:16] iunlink can not be unset from ctx!=0, right? [22:16] should not be possible ... otherwise it's a bug ;) [22:17] when you prohibit chmod(...) on such a dir, it should work [22:19] that was my idea ... [22:32] serving- (~serving@213.186.188.205) joined #vserver. [22:33] [HvD] (~guess@62.99.252.14) got netsplit. [22:33] serving (~serving@213.186.188.205) got netsplit. [22:33] Medivh (ck@62.93.217.199) got netsplit. [22:33] Medivh (ck@62.93.217.199) returned to #vserver. [22:33] Topic changed on #vserver by !proton.oftc.net: http://linux-vserver.org/ || latest stable 1.25, devel 1.3.6, exp 0.06 [22:33] [HvD] (~guess@62.99.252.14) returned to #vserver. [22:36] ensc: okay, verified, that is a doable solution for now ... [22:41] ah... I think I got this --rbind stuff to work [22:41] hey, that would be great, what is it? [22:42] try: new-namespace bash [22:42] (from alpha-tools) [22:42] mount --rbind /vservers/... / [22:42] vserver ... start [22:42] now login with ssh into this vserver and try an exploit [22:43] okay, my mount doesn't support --rbind :( [22:43] which mount do you use? [22:44] serving (~serving@213.186.188.205) got lost in the net-split. [22:44] but that means, that it _does_ work without kernel hack?! [22:44] from util-linux 2.12pre [22:44] yes [22:45] hehe great enrico! [22:45] but 'vserver ... enter' does not work anymore [22:45] this needs a kernel hack [22:46] and my automounter seems to become crazy [22:49] miller7 (none@213.239.180.106) left irc: Read error: Connection reset by peer [22:50] okay, that was expected (vserver enter) we have to do the 'namespace' migration ... [23:20] Doener_zZz (~doener@pD9E121EE.dip.t-dialin.net) joined #vserver. [23:23] serving- (~serving@213.186.188.205) left irc: Read error: Connection reset by peer [23:28] Doener (~doener@pD9E12286.dip.t-dialin.net) left irc: Ping timeout: 501 seconds [23:39] when will the new patch be ready? [23:40] in a minute or so ... [23:40] :) [23:42] http://vserver.13thfloor.at/Experimental/delta-vs1.25-vs1.26.diff [23:51] nice that the css bug thing is found :) [23:52] ooh 1.25 is out [23:53] hey meebey! [23:53] in 10 minutes 1.26 will be out ;) [23:53] "The stylesheet http://www.13thfloor.at/styles/13thfloor_gray.css was not loaded because its MIME type, "text/plain", is not "text/css"." [23:53] meebey: is the css issue fixed for you now? [23:53] hhmm [23:53] maybe proxy? [23:54] I guess so [23:54] Bertl: can you change 1 byte please? :) [23:54] add a \n or something [23:54] I bet proxies dont check for changed mimetypes [23:54] and make the cached page unusable for all others?# [23:54] sure I can ;) [23:54] :) [23:55] in 10 min? I will wait then for 1.26 :) [23:55] Bertl: btw I plan on making the util-vserver packages for debian [23:56] hmm, sounds good, stylesheet changed ... [23:56] Bertl: thx, fixed :) [23:57] great, didn't know that this could be an issue ... [23:59] with proxies? [23:59] nope, the test/css vs. text/plain ;) [23:59] yeah didnt know that too [23:59] well, I still don't understand why apache sends it as text/plain if not specified explicitely ... [23:59] I guess its default that apache has the mimetype for it? [00:00] --- Sat Feb 7 2004