[18:01] <kees> jdstrand, mdeslaur: \o
[18:02] <mdeslaur> hola!
[18:03] <jdstrand> o/
[18:03] <kees> okidoky
[18:03] <kees> i'm doing community bits, just came off of triage
[18:04] <kees> last week was filled with embargoed upstream issues.  no idea why we got like 4 at once, but they're all in process now.
[18:05] <kees> I'll be probably taking fetchmail and anything else I can find.  the next kernel update is pending, so that will need attention too.
[18:05] <kees> mdeslaur: you're up!
[18:05] <mdeslaur> I'm on triage this week
[18:05] <mdeslaur> and am working on apache2
[18:05] <mdeslaur> I just published gnome-screensaver
[18:05] <mdeslaur> and I'll probably pick out something else
[18:05] <mdeslaur> that's it
[18:05] <jdstrand> I'll go
[18:06]  * kees wonders when the g-ss love-in will end
[18:06] <mdeslaur> hehe
[18:06] <nxvl> hello
[18:06] <kees> heya nxvl
[18:06] <jdstrand> last week I was on community. we published our first UCSN (Ubuntu Community Security Notice). more will need to happen with automation as we move forward
[18:07] <jdstrand> most of last week was spent on moin for the latest CVEs. I imagine this week will be the same. lots of commits to wade through. I have prelim patches for intrepid and higher
[18:07] <jdstrand> I've started writing patches for 1.5 (dapper and hardy), since upstream is not interested
[18:08] <kees> jdstrand: yeah, that looks like quite a giant set of changes.  yay for CSRF
[18:08]  * jdstrand nods
[18:08] <jdstrand> the code is quite different between the two, but the fix is easy enough to understand and write-- just need to get the fixes in all the right sports (which is the trick)
[18:09] <jdstrand> s/the two/1.5 and 1.7/
[18:09]  * kees nods
[18:09] <jdstrand> beyond that, I am working on the ff apparmor profile and apparmor abstractions. I should be done with that today so people can be running that for a while
[18:10] <jdstrand> I also will be on vacation next week and the following monday, so you won't hear from me for a while :)
[18:10] <kees> yay vacation!
[18:10] <jdstrand> \o/
[18:10] <kees> going anywhere fun, or is it a staycation?
[18:11] <jdstrand> cruise in the carribbean
[18:11] <kees> niiiice
[18:11] <jdstrand> caribbean
[18:11] <jdstrand> yeah, it should be fun. I will not be available on irc though :P
[18:11] <jdstrand> that's it from me
[18:11] <kees> set up DNS tunnelling before you go; I bet they have wifi.  ;)
[18:12] <kees> any other issues for the security team?
[18:12] <jdstrand> kees: well... I will have a laptop, but I don't want to get pinged ;)
[18:12] <mdeslaur> yeah, bug #103010
[18:12] <mdeslaur> kirkland would like a statement from the security team
[18:12]  * kees reads
[18:15] <kees> I need a lot more information about this bug before I can really say anything useful.
[18:15] <jdstrand> I would agree
[18:15] <kees> kirkland: what's involved in setting up a tun/tap thing for kvm?
[18:15] <jdstrand> I can say that the recommended Ubuntu way to do virtualization is to use libvirt
[18:15] <kees> i.e. is it possible to have kvm drop the cap after setting it up?
[18:15] <jdstrand> libvirt handles this on qemu's behelf in multiple ways
[18:16] <kees> does it give a user arbitrary control over tun/tap devices (i.e. could they disrupt openvpn, etc)
[18:16] <kirkland> kees: i don't know; haven't tried it
[18:16] <kirkland> kees: but several people per release ask about this, and vte networking
[18:16] <kees> vts?
[18:16] <kees> er
[18:16] <kees> vte?
[18:16] <kirkland> kees: fat finger ... vde
[18:17] <kirkland> libvdeplug2 - Virtual Distributed Ethernet - Plug library
[18:17]  * kees doesn't know what that is either.  :)  intreseting
[18:17] <kees> i so cannot type today
[18:17]  * kirkland either
[18:17] <jdstrand> the kidsquid.com link is dead
[18:18] <kees> kirkland: so, the issue is that people are trying to use kvm without running it as root.  is the only issue networking?
[18:19] <jdstrand> kees: fyi-- qemu has a non-tun/tap way of doing networking as well, but it isn't nearly as useful
[18:19] <kirkland> kees: i don't know, honestly;  like jdstrand says, we have a recommended way of doing things, and these deviations from the norm are not ones i'm familiar with
[18:20] <kees> kirkland: what are the recommended configurations?  (is there a list/wiki somewhere?)
[18:20] <mdeslaur> I don't think it's sane for a regular user without admin privileges to be able to play with networking settings
[18:20] <kirkland> kees: https://help.ubuntu.com/community/KVM/Networking
[18:21] <jdstrand> mdeslaur: I think it depends on what qemu does. but, my feeling is that more than just creating this device is needed. setting up a tun/tap device with qemu used to require helper scripts, ifconfig, ...
[18:22] <jdstrand> is it me, or is that page a hodge-podge
[18:22] <jdstrand> it says KVM, and even has setcap, but then mentions libvirt and xml later
[18:23] <jdstrand> I thought there was an official page on all of this?
[18:23] <kees> so, I don't like recommending "cap_net_admin=ep".  I would prefer "cap_net_admin=ei" I think, and have a user with cap_net_admin=i, but I don't know how to set a user's inheritable caps
[18:24] <kirkland> jdstrand: it's a mess
[18:24] <kirkland> jdstrand: i cleaned it up some time ago, and it devolves down to a collection of hacks
[18:24] <jdstrand> kirkland: I thought you did work on the wiki-- but I thought it was somehwere else... the server guide?
[18:25] <kirkland> jdstrand: it was all in the wiki
[18:25] <kirkland> jdstrand: i split up the docs for kvm, virsh, virt-manager
[18:25] <jdstrand> https://help.ubuntu.com/9.10/serverguide/C/virtualization.html
[18:25] <kirkland> jdstrand: cleaned that up
[18:26] <kees> ok, here's what I'd like to see:
[18:26]  * jdstrand wonders if s/KVM/Virtualization/ would be more appropriate for the wiki, since it seems to cover kvm+libvirt
[18:27] <kees> 1) qemu should drop caps when they're no longer needed
[18:27] <kees> 2) documentation should be cleaned up a bit
[18:27] <kees> 3) docs should include a "why" on this -- giving everyone on the system cap_net_admin via qemu is not safe
[18:27] <kees> 4) bug should stay closed, with a pointer to the docs
[18:27] <jdstrand> kirkland: I'm thinking people edited KVM/Networking after you...
[18:28] <kirkland> jdstrand: ack
[18:28] <kees> The ultimate solution is to ship qemu with cap_net_admin=ei and document how to set a specific user to have cap_net_admin=i
[18:28] <kirkland> kees: which of those todo's are for me?
[18:28] <jdstrand> kees: making sure qemu drops it soon...
[18:28] <kees> kirkland: dunno; just talking out loud so far
[18:29] <kees> the "1" could probably wait, though perhaps it needs to keep it forever -- I really don't know what it needs to be doing to the tun/tap
[18:29] <jdstrand> kees: the setcap commenter in the bug I think added the setcap in the wiki, fwiw
[18:30] <jdstrand> ligouri could speak to that
[18:30] <jdstrand> (the '1' bit)
[18:31] <jdstrand> kees: does setcap work on nfs?
[18:31] <kees> kirkland: can you open a bug for #1, and update the docs for 2,3,4?
[18:31] <kees> jdstrand: if xattr works on the remote fs, I think so yes.
[18:31] <jdstrand> I think it would then...
[18:32] <kees> kirkland: I'm investigating how to do this "correctly", but it kind of requires fscaps support in dpkg, which isn't likely to happen until M.
[18:32]  * jdstrand was just thinking about the lontime problem of fscaps and filesystems
[18:32] <kirkland> kees: i can open that bug soon-ish; doc's won't be updated for a good while
[18:32] <kirkland> kees: probably not until we hit rc, when i hope i get a breath
[18:33] <kees> kirkland: well, I can take 3 and 4 if you want.  2 isn't really needed, I guess.
[18:33] <kirkland> kees: sounds good
[18:37] <kees> kirkland: okay, I've done 3 and 4.
[18:37] <kees> kirkland: you'll probably want to create a FAQ or something.
[18:37] <kirkland> kees: thanks, i'll get the other one opened, and get a pointer from anthony
[18:38] <kees> okay, anything else for the security team?
[18:39]  * kees takes that as a "no".  meeting done.  :)  thanks everyone!
[18:40] <mdeslaur> thanks everyone