<     May 2017     >
Su Mo Tu We Th Fr Sa  
    1  2  3  4  5  6  
 7  8  9 10 11 12 13  
14 15 16 17 18 19 20  
21 22 23 24 25 26 27  
28 29 30 31
00:10 grayhemp joined
00:17 lestus joined
00:18 <lestus> heya
00:18 <Shiz> hello
00:18 <lestus> discovered alpine 2 days ago
00:18 <lestus> o.0
00:18 <lestus> feel like i been living under a rock
00:19 <lestus> exactly what i needed
00:20 <lestus> Shiz: how's things?
00:21 flazz2 joined
00:26 rivarun joined
00:27 <Shiz> welp
00:31 grayhemp joined
00:37 flazz2 joined
00:38 rdutra joined
00:44 jackmcbarn joined
00:50 Fooster joined
01:00 grayhemp joined
01:03 grayhemp_ joined
01:12 rivarun joined
01:17 flazz2 joined
01:21 czart__ joined
01:29 grayhemp joined
01:35 s33se joined
01:37 flazz2 joined
01:57 flazz2 joined
02:12 vidr joined
02:16 flazz2 joined
02:22 cydrobolt joined
02:38 flazz2 joined
02:47 dalias joined
02:50 blackwind_123 joined
02:50 syntrx joined
02:58 flazz2 joined
03:06 grayhemp joined
03:14 mdillon joined
03:17 kvda_ joined
03:23 Classsic_ joined
03:23 flazz2 joined
03:29 mdillon joined
03:37 tmh1999_2 joined
03:40 flazz2 joined
03:40 tmh1999_2 joined
03:55 tbrock joined
03:57 flazz2 joined
04:04 <tbrock> hey everyone, i'm trying to run crond as a non-root user within a container, specifying a specific crondir that only contains my user's crontab
04:04 <tbrock> however when it runs I see crond: "can't set groups: Operation not permitted"
04:04 <tbrock> and the command does not execute
04:05 <tbrock> when i run the container as the root user with docker's -u flag specifying root, it runs just fine
04:05 <tbrock> any ideas on why that may be the case?
04:08 grayhemp joined
04:16 Somasis joined
04:16 Somasis joined
04:17 flazz2 joined
04:17 dasher00 joined
04:17 tmh1999 joined
04:19 kvda joined
04:20 tmh1999 joined
04:23 rafalcpp joined
04:25 dasher00 joined
04:26 amosbird joined
04:33 <Shiz> tbrock: crond is not meant to be ran as non-root
04:34 <Shiz> at least not busybox crond
04:34 <Shiz> maybe another cron will do what you want
04:38 flazz2 joined
04:40 thunfisch joined
04:46 greguu joined
04:47 <tbrock> @Shiz why not? doesn't that seem odd (not trying to be argumentative)
04:47 <tbrock> thanks for responding btw
04:47 <Shiz> I dunno, I didn't develop it :P
04:48 <Shiz> but looking at the source code it very much expects to be ran as root
04:48 <Shiz> as a system cron I'd imagine
04:48 <Shiz> we package a few other crons like fcron and dcron, they may be able to run as a normal user
04:51 <tbrock> ok, cool thanks
04:51 <tbrock> what was the giveaway that it expects to run as root?
04:51 <tbrock> if i take a look at the code myself
04:51 <Shiz> it dropping permissions :P
04:51 <Shiz> you can't drop permissions as a normal user to yourself
04:52 <Shiz> https://git.busybox.net/busybox/tree/miscutils/crond.c#n592
04:53 <Shiz> as well as a more explicit reference here: https://git.busybox.net/busybox/tree/miscutils/crond.c#n118
04:54 <Shiz> and here: https://git.busybox.net/busybox/tree/miscutils/crond.c#n3
04:56 flazz2 joined
05:00 mdillon joined
05:06 fabled joined
05:17 mrEngineer joined
05:18 flazz2 joined
05:32 tmh1999_2 joined
05:34 gogoprog joined
05:39 flazz2 joined
05:56 flazz2 joined
06:18 flazz2 joined
06:23 grayhemp joined
06:38 arnotixe joined
06:40 flazz2 joined
06:43 blackwind_123 joined
06:44 arnotixe1 joined
06:45 t0mmy joined
06:47 k0nsl joined
06:48 k0nsl joined
06:57 flazz2 joined
07:18 flazz2 joined
07:29 royger joined
07:33 dave_9911 joined
07:40 flazz2 joined
07:42 rollniak joined
07:54 tbrock joined
07:56 flazz2 joined
07:58 rollniak_ joined
08:09 rivarun joined
08:11 cyborg-one joined
08:19 flazz2 joined
08:40 flazz2 joined
08:48 kaniini joined
08:49 mattaitchison joined
08:50 Kooda[b] joined
08:50 Madgod joined
08:51 arenstar joined
08:51 ericnoan joined
08:51 clandmeter joined
08:57 grayhemp joined
08:57 flazz2 joined
09:03 fekepp joined
09:16 flazz2 joined
09:21 Fishfish0001 joined
09:24 <amosbird> Hi, why am I getting this https://la.wentropy.com/KyT4 ?
09:29 psychi[m] joined
09:29 hl joined
09:29 copumpkin joined
09:29 itsfemme[m] joined
09:29 xs[m] joined
09:29 ganlub joined
09:29 Kooda joined
09:29 dhole[m] joined
09:29 budric[m] joined
09:29 fish_ joined
09:36 flazz2 joined
09:56 flazz2 joined
09:57 ahrs joined
10:16 flazz2 joined
10:39 flazz2 joined
10:46 cyteen joined
10:50 Fooster joined
10:58 flazz2 joined
11:11 <mnemoc> Shiz: hi, another cross-compile related problem :( http://sprunge.us/PXXN .... it shouldn't be mkdir-ing in /usr/lib/go/ but in $WORK
11:15 <mnemoc> Shiz: same happens doing FROM alpine:edge instead of node:alpine + go@edge
11:16 flazz2 joined
11:34 ogres joined
11:38 <mnemoc> Shiz: http://sprunge.us/STIN <--- native too :'(
11:41 lesion joined
11:41 <* mnemoc> scratches his head
11:42 flazz2 joined
11:45 argulp joined
11:53 rdutra joined
11:54 tbrock joined
11:55 rdutra joined
11:59 flazz2 joined
12:02 grayhemp joined
12:13 kaniini joined
12:14 johansglock joined
12:14 ageis joined
12:14 rxc joined
12:14 nwmcsween joined
12:16 gromero joined
12:37 tmh1999_2 joined
12:37 flazz2 joined
12:45 hl joined
12:45 copumpkin joined
12:45 psychi[m] joined
12:45 itsfemme[m] joined
12:45 ganlub joined
12:45 xs[m] joined
12:45 dhole[m] joined
12:45 budric[m] joined
12:45 Kooda joined
12:45 fish_ joined
12:47 t0mmy joined
12:56 fekepp joined
12:58 flazz2 joined
13:00 farosas joined
13:03 fekepp joined
13:16 flazz2 joined
13:22 stateless joined
13:37 flazz2 joined
13:38 tbrock joined
13:43 t0mmy joined
13:44 robru joined
13:46 fekepp joined
13:47 Kruppt joined
13:54 BitL0G1c joined
13:58 flazz2 joined
14:08 vidr joined
14:15 k0nsl joined
14:15 k0nsl joined
14:17 flazz2 joined
14:17 k0nsl joined
14:17 k0nsl joined
14:20 <mnemoc> Shiz: btw, passing -pkgdir solves the "write to /usr/lib/go/" thing
14:31 Skele joined
14:33 <ncopa> hm.. setup-xorg-base does not work with qemu
14:33 <ncopa> std vga
14:33 <ncopa> i dont know which xf86-video-* that should be used
14:36 <_ikke_> hold on, i've set it up once, with guidance from someone here
14:38 flazz2 joined
14:38 <BitL0G1c> qemu + spice uses xf86-video-qxl
14:38 <BitL0G1c> ncopa ^^^
14:39 <ncopa> that is -vga qxl right?
14:39 <ncopa> i've used that too
14:40 <BitL0G1c> I used virt-viewer to connect
14:40 <ncopa> but the qemu default '-vga std' does not work
14:41 <ncopa> hm
14:41 kvda joined
14:41 <ncopa> qemu with gtk support and -vga vmware does not seem to work either
14:42 mmlb joined
14:42 <parazyd> ncopa: it complains about not finding /dev/dri or no permissions?
14:43 <ncopa> no
14:44 <BitL0G1c> my old notes for spice https://it-offshore.co.uk/linux/alpine-linux/30-alpine-linux-spice-kvm-desktop
14:44 <_ikke_> ncopa: apparently I did not use -vga at all
14:44 <_ikke_> ncopa: just -spice port=...
14:44 <ncopa> the default since qem 2.2 is -vga std
14:45 <ncopa> as i understand
14:45 <ncopa> but i cannot get it work
14:45 <_ikke_> ncopa: what is the issue?
14:45 <ncopa> xorg does not start at all
14:45 <ncopa> would be nice to be able to set up xorg in a default qemu
14:47 <_ikke_> ncopa: I did have it working
14:47 <parazyd> me too
14:48 <Shiz> ncopa: got any /dev/dri devices?
14:48 <ncopa> yes
14:49 <ncopa> it just exited with error
14:49 cyborg-one joined
14:49 <ncopa> when i installed mesa-dri-swrast it would hang
14:49 <parazyd> so what does the xorg log say?
14:49 <ncopa> i'll grep EE
14:49 <parazyd> (also keep in mind in gentoo modesetting still isn't working properly on musl)
14:51 <ncopa> aha
14:51 <ncopa> with mesa swrast installed it just hanged im rebooting now to look at the xorg.log
14:52 k0nsl joined
14:52 k0nsl joined
14:52 <ncopa> http://tpaste.us/xWr1
14:54 <ncopa> and without mesa-dri-swrast installed: http://tpaste.us/ya0p
14:54 <ncopa> http://tpaste.us/yaOp
14:55 k0nsl joined
14:55 k0nsl joined
14:57 k0nsl joined
14:57 k0nsl joined
14:58 <Shiz> ncopa: id drop mesa-dri-swrast and try xf86-video-fbdev
14:59 <parazyd> hmm never seen that happen before
14:59 <ncopa> with xf86-video-fbdev: grep EE /var/log/Xorg.0.log
14:59 flazz2 joined
14:59 <ncopa> http://tpaste.us/Yn0r
14:59 <parazyd> try vesa and/or fbdev indeed
15:00 <ncopa> same error with xf86-video-vesa installed
15:00 <ncopa> apk search glamor
15:00 <parazyd> ncopa: make sure swrast_dri isn't in /usr/lib/dri rather than /usr/lib/xorg/modules/dri
15:01 emacsoma` joined
15:01 <ncopa> thats how it is
15:01 <ncopa> i wonder if i am missing some kernel module
15:01 <parazyd> no, i thought... where is swrast_dri.so on your system?
15:02 <ncopa> http://tpaste.us/vMWo
15:03 <parazyd> stupid questions now, but did you try to `ldd` it?
15:03 <parazyd> i'm not sure what's the culprit of this error
15:03 <ncopa> the error happens when mesa-dri-swrast is not installed at all
15:04 <ncopa> when it is installed it will hang
15:04 <parazyd> i see. hmm that's even a tougher nut
15:06 <ncopa> ok this is intersting, glamor-egl has conflict with xorg-server
15:06 <Classsic> hi, somebody try install alpine on baytrail device?
15:07 leo-unglaub1 joined
15:13 grayhemp joined
15:15 grayhemp joined
15:17 flazz2 joined
15:19 t0mmy joined
15:19 <ncopa> i think i give up this qemu xorg thing
15:22 grayhemp joined
15:27 <_ikke_> ncopa: :-(
15:28 <parazyd> ncopa: have you tried with -vga virtio
15:29 <parazyd> that's the only useful one tbh
15:29 <parazyd> at least gives you a proper screen resolution rather than these tiny ones
15:30 arnotixe joined
15:30 <ncopa> which xf86-video- driver should be used with virtio?
15:33 grayhemp joined
15:34 <ncopa> looks like both arch linux and fedora has some patches to xorg-server
15:35 <_ikke_> ncopa: hold on, I'm starting my qemu vm again to see what I've installed
15:46 <_ikke_> ncopa: so I have my vm running
15:47 <_ikke_> ncopa: I have xf86-video-vesa and xf86-video-modesetting installed
15:48 <_ikke_> ncopa: running without -vga settings
15:49 <ncopa> which xorg server version and what version of libdrm?
15:50 <_ikke_> xorg-server-1.18.4-r3
15:50 <_ikke_> libdrm-2.4.74-r0
15:53 <ncopa> ok so something broken in xorg-1.19
15:53 <_ikke_> performing an upgrade now, see if it breaks
15:54 <parazyd> ncopa: iirc 1.19 merged the modesetting driver
15:54 <parazyd> it's not separate from xorg-server anymore
15:55 <ncopa> there is a modesetting_drv.so
15:56 <_ikke_> ncopa: working with 1.19
15:58 ericnoan joined
16:08 grayhemp joined
16:09 <ncopa> hm
16:10 <_ikke_> Is vim broken in edge?
16:10 <ncopa> not that i know
16:10 <_ikke_> I get a whole load of lua_* symbol not found errors
16:13 ericnoan joined
16:14 mwbrown joined
16:16 grayhemp joined
16:17 mmlb joined
16:20 <_ikke_> ncopa: weird glitch with my system, reboot fixed it
16:20 <_ikke_> mount somehow got read-only
16:21 ericnoan joined
16:28 ericnoan joined
16:45 arnotixe1 joined
16:58 grayhemp joined
17:10 orbiter joined
17:17 arnotixe1 joined
17:25 ephemer0l joined
17:25 ephemer0l joined
17:25 emacsomancer joined
17:25 t0mmy joined
17:27 sergey_ joined
17:30 tmh1999 joined
17:30 ephemer0l joined
17:30 ephemer0l joined
17:32 grayhemp_ joined
17:33 AlexIncogito joined
17:34 ncl joined
17:36 grayhemp_ joined
17:39 tbrock joined
17:41 letoram joined
17:57 grayhemp joined
18:00 blackwind_123 joined
18:03 rivarun joined
18:13 mwbrown joined
18:23 Fooster joined
18:30 arnotixe joined
18:38 preyalone joined
18:40 fekepp joined
18:46 Fishfish0001 joined
18:46 minimalism joined
18:57 Kruppt joined
19:00 clandmeter joined
19:14 rivarun joined
19:24 dlaube1 joined
19:34 tbrock joined
19:53 rollniak joined
20:35 t0mmy joined
20:50 mrEngineer joined
21:04 grayhemp joined
21:23 mrEngineer joined
21:24 tbrock joined
22:11 zocker joined
22:29 moul joined
22:59 rdutra joined
23:04 kvda joined
23:07 jvoisin joined
23:08 atrigent joined
23:09 <atrigent> I have a docker image where I'm running the unzip command, and I get this error: "error: zipfile probably corrupt (illegal instruction)" when trying to unzip a file
23:09 <atrigent> this file unzip fine with other copies of unzip
23:09 <atrigent> i.e. copies other than alpine's
23:11 <atrigent> I ran the command with gdb and it seems that unzip is deliberately raising an illegal instruction exception with the ud2 instruction
23:11 <atrigent> so, like, what???
23:13 ephemer0l joined
23:21 czart_ joined
23:24 <Shiz> atrigent: ub possibly
23:24 <BitL0G1c> atrigent - check the command line switches on busybox unzip - or add unzip to the docker image
23:25 <atrigent> BitL0G1c: I don't think I'm using busybox unzip, I wasn't even aware there was such a thing
23:25 <Shiz> if you haven't installed any unzip package, yo're using busybox unzi
23:25 <Shiz> p
23:25 <BitL0G1c> lrwxrwxrwx 1 root root 12 Sep 14 2016 /usr/bin/unzip -> /bin/busybox*
23:26 <atrigent> I installed unzip
23:26 <Shiz> try just using busybox unzip :p
23:26 <Shiz> atrigent: btw the reason for the ud2 instruction is likely musl
23:27 <Shiz> on fatal API abuses, it invokes a_crash() (which is the ud2 instr on x86_64)
23:27 <Shiz> to ease debuggability, because now your backtrace directly leads to the offending call
23:27 <atrigent> in gdb, it looked like the ud2 instruction was inside the unzip command itself, not musl
23:27 <atrigent> but I dunno, maybe something got inlined
23:28 <BitL0G1c> busybox unzip cmd switches - https://pastebin.com/raw/j5Phs4BG
23:28 <Shiz> if you can use the busybox unzip impl, i'd try to see if that works
23:29 <atrigent> so, the reason that I'm having to use the unzip command is that I need to extract some files that use deflate64 compression, and busybox does not seem to support that
23:29 <atrigent> I'd be using the python zipfile module otherwise
23:29 <Shiz> ah, right
23:30 <atrigent> Shiz: any way to get debug info for the unzip command...?
23:30 <Shiz> sadly doesn't seem that way, some packages have a -dbg subpackage, but it seems unzip doesn't right now
23:30 <Shiz> it's something we are looking into extending across all packages...
23:31 <atrigent> ah ok yeah, I guess I can't tell whether it's in musl or not
23:32 <Shiz> it seems there is no direct use ud2 within unzop
23:32 <Shiz> unzip
23:32 ephemer0l joined
23:32 <atrigent> any way to get musl to be more verbose?
23:32 <Shiz> oh, hmm
23:32 <Shiz> it seems musl a_crash() uses halt, not ud2
23:33 <Shiz> so it seems gcc generates ud2 instructions in some cases, likely for a similar reason
23:33 kvda joined
23:33 <Shiz> fatal runtime error
23:34 <Shiz> probably because there's UB in the unzip source code
23:35 <Shiz> atrigent: what alpine version is this?
23:35 <atrigent> 3.5
23:36 <Shiz> i'll take a look at it, but there's no direct solution i can offer you right now
23:36 <Shiz> except from using an alternative zip impl, of course
23:36 <atrigent> as far as I can tell the only other open-source implementation that supports deflate64 is 7zip, which doesn't seem to be in alpine
23:36 <Shiz> but it is
23:36 <Shiz> the p7zip package :)
23:37 <atrigent> alright, I spose I'll try that
23:38 tbrock joined
23:40 <atrigent> seems to be working better
23:40 <Shiz> my current idea is that unzip does something to invoke gcc's __builtin_trap()
23:40 <Shiz> which compiles to ud2
23:41 andypost joined
23:43 kvda_ joined
23:51 BitL0G1c joined
23:53 <atrigent> Shiz: does alpine compile stuff with more flags for detecting ub? because a copy of the same version of unzip running on ubuntu does not crash
23:53 <Xe> atrigent: are you running on grsec or non-grsec kernel?
23:53 <atrigent> uh I dunno, it's an ec2 instance
23:53 <atrigent> hah
23:53 <atrigent> probably not?
23:54 <Xe> $ uname -av
23:54 <Shiz> ec2 wont be hardened, probabl
23:54 <Xe> Shiz: depends on who made the image :P
23:54 <Shiz> and also, the kernel won't emit ud2's in userspace for you
23:54 <Shiz> lol
23:54 <atrigent> yeah looks like not
23:54 <Shiz> it'll just send the proc a SIGKILL
23:54 <Shiz> or SIGSEGV
23:55 <Shiz> depending on the violation
23:55 <Shiz> atrigent: no additional flags that i directly can see, no
23:58 <atrigent> the ubuntu copy was compiled with an older version of gcc, so maybe some stuff just got turned on by default or something
23:58 <atrigent> meh