1346980706 J * bergerx_ ~bergerx@178.233.12.223
1346981144 Q * bergerx___ Ping timeout: 480 seconds
1346983883 Q * jeroen__ Ping timeout: 480 seconds
1346984427 J * jeroen__ ~jeroen@mail.searchtrends.eu
1346984608 J * bergerx___ ~bergerx@178.233.12.223
1346985049 Q * bergerx_ Ping timeout: 480 seconds
1346988043 Q * nkukard Ping timeout: 480 seconds
1346988137 J * nkukard ~nkukard@41-133-165-27.dsl.mweb.co.za
1346989698 Q * nakacya Remote host closed the connection
1346989722 J * nakacya ~nakacya@KD118152083243.ppp-bb.dion.ne.jp
1346990210 Q * nakacya Ping timeout: 480 seconds
1346993671 M * Bertl off to bed now ... have a good one everyone!
1346993676 N * Bertl Bertl_zZ
1346995396 J * ghislain ~AQUEOS@adsl2.aqueos.com
1346997938 J * nakacya ~nakacya@KD118152083243.ppp-bb.dion.ne.jp
1347008705 J * fisted_ ~fisted@xdsl-84-44-220-157.netcologne.de
1347009029 Q * fisted Ping timeout: 480 seconds
1347009251 Q * FireEgl Quit: Leaving...
1347009438 J * ghislain1 ~AQUEOS@adsl2.aqueos.com
1347009622 J * FireEgl FireEgl@2001:470:e5ad:1:61d0:f914:2a4a:d117
1347009682 Q * ghislain Ping timeout: 480 seconds
1347011425 J * kir ~kir@swsoft-msk-nat.sw.ru
1347011486 P * kir 
1347012068 Q * nakacya Remote host closed the connection
1347012091 J * nakacya ~nakacya@KD118152083243.ppp-bb.dion.ne.jp
1347012578 Q * nakacya Ping timeout: 480 seconds
1347014161 J * nakacya ~nakacya@KD118152083243.ppp-bb.dion.ne.jp
1347015530 J * aperezdc ~aperez@dsl-hkibrasgw3-fe7cfb00-20.dhcp.inet.fi
1347015645 M * aperezdc hello! I was playing with linux-user-chroot (http://git.gnome.org/browse/linux-user-chroot) and had to patch it to work inside a vServer guest
1347015650 M * aperezdc the patch is this: https://github.com/aperezdc/linux-user-chroot/commit/da3963fde7b
1347015682 M * aperezdc essentially, it disables the CLONE_NEWNET flag
1347015697 M * aperezdc and avoids a call to prctl(PR_SET_NO_NEW_PRIVS, 1)
1347015738 M * aperezdc wouldn't it be desirable that at least PR_SET_NO_NEW_PRIVS could be used inside a guest?
1347018722 M * DelTree chroot inside vserver ?
1347019259 J * clopez ~clopez@17.28.165.83.dynamic.mundo-r.com
1347019271 M * aperezdc DelTree: yes
1347019286 M * DelTree -M
1347019290 M * DelTree oops...
1347019300 M * aperezdc that helper tool is used by ostbuild, a jhbuild replacement in the works to be used for GNOME development
1347019337 M * aperezdc I have stumbled upon that issue while setting up a buildbot for gnome w/ostbuild inside a vserver container
1347019427 M * aperezdc as a proposal, I'm suggesting to have a config setting for changing the chroot helper that ostbuild uses (see https://mail.gnome.org/archives/ostree-list/2012-September/msg00005.html )
1347019494 M * aperezdc but we don't see any reason why not allowing “prctl(PR_SET_NO_NEW_PRIVS, 1)” inside vserver (BTW, if some extra capability is enabled, like CAP_SYS_ADMIN)
1347021514 J * BenG ~bengreen@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com
1347022049 Q * BenG Quit: I Leave
1347022084 M * Chlorek damn
1347022170 M * Chlorek ser: did you find solution to run upstart in guest?
1347024283 Q * ensc|w Remote host closed the connection
1347024293 J * ensc|w ~ensc@www.sigma-chemnitz.de
1347024301 N * Bertl_zZ Bertl
1347024307 M * Bertl morning folks!
1347024358 M * Bertl aperezdc: CLONE_NEWNET is something specified by userspace, so that sounds like a bug in the chroot tool
1347024380 M * Bertl aperezdc: will look into the PR_SET_NO_NEW_PRIVS
1347024472 M * aperezdc Bertl: mmh, the tool does add CLONE_NEWNET to the flags passed to clone(), and in that case I get an “operation not permitted (EPERM)”
1347024500 M * Bertl yes, so the question is, why does it add that?
1347024521 M * aperezdc ah, now I understand your question :)
1347024547 M * Bertl you can still work around that if you don't use network namespaces by simply disabling them in the kernel
1347024583 M * Bertl and you probably don't want to give CAP_SYS_ADMIN to a guest
1347024589 M * aperezdc the use of the linux-user-chroot tool is to build packages: as there is no need for the build process to access the network, the idea is to have a separate network NS, so it does not access the net
1347024621 M * Bertl so it should at least be configureable/selectable
1347024659 M * aperezdc nah, in the long term what we will do is having a configuration option for the chroot helper used
1347024668 M * aperezdc the question was more about the prctl() call
1347024684 M * aperezdc thanks for taking a look at it :)
1347024699 M * Bertl 'we' sounds interesting, so you are a/the developer of this tool?
1347024719 Q * arekm Read error: Connection reset by peer
1347024772 M * aperezdc well, Colin Walters made it for ostbuild (a new build system for GNOME), but a while ago I started looking at it, too
1347024798 M * aperezdc the “we” in there == people using the bleeding edge ostbuild now, or hacking on it
1347024875 M * Bertl thing is, I see no problem to find an acceptable solution if there is interest on both sides to get it working
1347024939 M * Bertl and usually there is no problem on 'our' side to add/adapt things as long as it a) does not reduce/circumvent the security and b) it is actively used by someone
1347024976 M * Bertl and of course, it should always get closer to the host system
1347025022 M * Bertl I see that the prctl is checked against certain security checks, mainly cap_task_prctl() in Linux-VServer 
1347025046 M * aperezdc if the prcrl() works, we will be using it for sure
1347025071 M * aperezdc but I dunno if there is anyone else out there using it inside vServer guests
1347025078 M * aperezdc seems a bit corner-case
1347025171 M * Bertl the PR_SET_NO_NEW_PRIVS sounds like it prevents adding capabilities?
1347025224 M * aperezdc yes, exactly, the idea is that building a package is not expected to need extra capabilities, so it should be forbidden to let processes gain new ones
1347025253 M * aperezdc unless I am missing something, I doubt it would be a security problem to let that work in a guest
1347025272 M * Bertl you are aware that the capability set is handled slightly different inside a Linux-VServer guest?
1347025342 M * aperezdc Bertl: no, i was not aware of that detail
1347025366 M * Bertl basically there is a set of capabilities which is given to a certain guest
1347025375 M * Bertl like the CAP_SYS_ADMIN you were giving
1347025398 M * Bertl which limits the capabilities inside a guest without showing that limit
1347025457 M * Bertl i.e. if you do not give CAP_SYS_ADMIN to the guest (which is strongly advised for security reasons) then the guest will not be able to 'use' CAP_SYS_ADMIN, but processes might still acquire that capability
1347025506 M * Bertl this was mainly done because of suid root and similar processes
1347025611 M * aperezdc mmh, interesting... so a process can have a capability acquired, but it would fail when it tries to call some function that actually uses it
1347025620 M * Bertl precisely
1347025751 M * Bertl regarding the PR_SET_NO_NEW_PRIVS, it seems to be quite new in the kernel, yes?
1347025810 M * aperezdc yes, it's pretty new
1347025823 M * aperezdc patches starting circulating lkml around last January
1347025835 M * Bertl as far as I can tell from the code, it isn't handled anywhere except in the syscall
1347025837 M * aperezdc IIRC they were merged around March-April
1347025908 M * Bertl I presume you are getting ENOSYS as return value yes?
1347026022 M * aperezdc yes
1347026063 M * Bertl looking at 3.5.x, I see that the syscall first invokes security_task_prctl() which in turn calls cap_task_prctl()
1347026091 M * Bertl which doesn't know about PR_SET_NO_NEW_PRIVS, and thus returns with ENOSYS
1347026134 M * Bertl now ENOSYS continues in sys_prctl() so no big deal yet
1347026195 M * Bertl and the commands are handled in a big switch/case
1347026208 M * Bertl so IMHO it is correctly executed
1347026246 M * Bertl (despite the fact that it returns ENOSYS, which might be considered a bug, but from the description it's even intentional)
1347026280 M * Bertl what if you do a PR_GET_NO_NEW_PRIVS after the 'failing' set?
1347026424 M * Bertl hmm, actually you shouldn't get ENOSYS (from looking at it a second time)
1347026445 M * Bertl because the error code is reset to 0 just before the switch()
1347026560 M * aperezdc mmhh, I was talking from memory, give me a second and I'll do a test run
1347026795 M * aperezdc oh, damn... prctl (PR_SET_NO_NEW_PRIVS, 1) → returns EINVAL
1347026809 M * aperezdc it's not ENOSYS
1347027032 M * Bertl hmm, EINVAL is interesting
1347027060 M * Bertl the obvious case is this one:
1347027066 M * Bertl if (arg2 != 1 || arg3 || arg4 || arg5)
1347027076 M * Bertl   return -EINVAL;
1347027100 M * Bertl but I guess you got that one right, otherwise it would fail on the host ... it does work on the host, yes?
1347027150 M * aperezdc it works on the host, yes
1347027215 M * Bertl do you have an additional security system activated, because I do not see where it could get to the EINVAL otherwise
1347027368 M * aperezdc not really
1347027390 M * aperezdc the linux-user-chroot is setuid, but I doubt that has something to do...
1347027400 M * aperezdc and it is executed by a non-root user
1347027534 M * Bertl well, the first thing is to figure out where your EINVAL comes from
1347027558 M * Bertl you have a kernel tree and a test system you can try some things on?
1347027589 M * Bertl (I'd suggest to use kvm for simplicity)
1347027647 M * aperezdc Bertl: I have been testing this in one of my company's machines, but it has some production stuff, I would need some time to get me a local kvm running and a fresh kernel tree
1347027674 M * aperezdc and probably won't have enough time today... shall we continue looking at this on Monday?
1347027691 M * Bertl okay, then please prepare that and get back to me once you're ready
1347027745 M * Bertl if you find me _oO or _zZ, you can start putting printk()s in the syscall and cap_task_prctl() in various places :)
1347027755 M * aperezdc Bertl: sure, will do
1347027772 M * aperezdc thanks for your time, now it's my turn to do some homework ;)
1347027866 M * Bertl you're welcome!
1347034473 Q * nicholi Remote host closed the connection
1347034492 J * nicholi ~nicholi@rrcs-76-79-196-34.west.biz.rr.com
1347034750 J * bonbons ~bonbons@2001:960:7ab:0:9944:2e98:17b1:932
1347038679 J * nlm ~nlm@host77.190-30-39.telecom.net.ar
1347039040 Q * nlm_ Ping timeout: 480 seconds
1347040338 M * Bertl nap attack .. bbl
1347040350 N * Bertl Bertl_zZ
1347043666 J * hparker ~hparker@2001:470:1f0f:32c:beae:c5ff:fe01:b647
1347044627 N * ensc Guest6166
1347044637 J * ensc ~irc-ensc@84.173.226.250
1347045018 Q * Guest6166 Ping timeout: 480 seconds
1347045142 Q * kermie Quit: http://www.mibbit.com ajax IRC Client
1347045506 N * Bertl_zZ Bertl_oO
1347045662 Q * fisted_ Read error: Connection reset by peer
1347045694 J * fisted ~fisted@xdsl-84-44-220-157.netcologne.de
1347046018 Q * nakacya Remote host closed the connection
1347046184 Q * fisted Ping timeout: 480 seconds
1347048200 J * fisted ~fisted@xdsl-84-44-220-157.netcologne.de
1347053790 J * sannes ~ace@cm-84.211.87.28.getinternet.no
1347053870 Q * cuba33ci Read error: Connection reset by peer
1347053935 J * cuba33ci ~cuba33ci@114-36-246-136.dynamic.hinet.net
1347054178 Q * sannes Remote host closed the connection
1347054747 J * fisted_ ~fisted@xdsl-87-78-182-106.netcologne.de
1347054804 Q * fisted_ 
1347054899 Q * fisted Ping timeout: 480 seconds
1347055751 Q * ghislain1 Quit: Leaving.
1347056409 J * fisted ~fisted@xdsl-87-78-182-106.netcologne.de