naccstokachu: np02:28
mupBug # changed: 1627893, 1632124, 1632306, 164225704:18
mupPR snapd#2740 closed: releasing snapd version 2.22 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2740>07:18
mupPR snapd#2738 closed: spread: remove state tar on project restore <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2738>07:29
mupPR snapd#2691 closed: tests: allow to install snapd debs from a ppa instead of building them <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2691>07:35
mupPR snapd#2693 closed: cmd: rename mountinfo to sc_mountinfo <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2693>08:17
mupPR snapd#2742 opened: tests: fix typo in systems name <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2742>08:39
mupPR snapd#2676 closed: cmd: collect string utilities in one module, add missing tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2676>09:59
zygagood morning10:11
zygasorry for joinling late, forgot I turned my server off10:11
popeyhttp://askubuntu.com/questions/877850/error-cannot-deliver-device-serial-request-unexpected-status-400 <- any snappy people can help this person out?10:12
zygapopey: hey10:13
zygapopey: most of the time when this happens is when people build their own model10:13
zygapopey: or use a board outside of the supported set10:13
mupPR snapd#2742 closed: tests: fix typo in systems name <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2742>10:20
mupPR snapd#2713 closed: cmd: fix issues uncovered by valgrind <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2713>10:25
mupPR snapd#2416 closed: cmd/snap-confine: add snap-confine command line parser module <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2416>10:26
mupPR snapd#2739 closed: tests: remove (some) garbage files found by restore cleanup analysis <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2739>10:26
mupPR snapd#2698 closed: asserts,interfaces/policy: add support for $SLOT()/$PLUG()/$MISSING in *-attributes constraints <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2698>11:00
mupPR snapd#2743 opened: debian: move the snap-confine packaging into snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/2743>11:02
=== hikiko is now known as hikiko|ln
mupBug #1648777 changed: writing a (3GB sized) x86 image to a 3GB SD card makes the filesystem resizing being skipped <Snappy:Invalid> <initramfs-tools-ubuntu-core (Ubuntu):Invalid by ogra> <https://launchpad.net/bugs/1648777>12:15
=== hikiko|ln is now known as hikiko
mupPR snapd#2658 closed: cmd: add mount / unmount helpers <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2658>12:44
kalikianaCannot find the definition for part 'desktop-ubuntu-app-platform'.13:01
kalikianaIt may be a remote part, run snapcraft update to refresh the remote parts cache.13:01
kalikiana^^ This seems to be a regression? Cloud parts used to be pulled in automatically13:02
kalikianaI was quite confused and it took me a bit to realize the part name wasn't wrong13:02
didrocksogra_: hey! what do you think about adding a configure/install hook on the classic snap running apt update to initialize the apt database for the user?13:04
ogra_didrocks, not much since that forces you to be online13:05
ogra_didrocks, well, we could add it with an online check i guess ... but the whole thing is designed so that you can also use it witouth being online at all13:06
didrocksogra_: well, when you install the snap, you are online already, correct? :)13:10
ogra_true indeed13:10
didrocksand it we can try to make it ran only at that time?13:11
didrocksI'm happy to have a shot at it13:11
didrocks(not today)13:11
didrocksbut just wanted to know if you were +1 first on it13:11
ogra_sure, the script that gets executed is actually shipped in the core snap13:11
ogra_and is only executed the first time you run "sudo classic"13:11
iceyseems like a snap installed app can't read from the keyboard?13:11
didrocksah, I was more thinking as a hook in the classic snap itself13:12
iceyalso, can't click on a link in the snapped app and open it in the system browser13:12
ogra_"read from the keyboard" ?13:12
ogra_do you have a camera attached ? :P13:12
ogra_didrocks, nah, it should just become part of the setup script ... the classic snap only calls this13:12
didrocksogra_: ok, do you have the repo reference handy? If not, no worry, I'll have a shot later anyway13:13
ogra_no repo ... it is part of the livecd-rootfs package in the image PPA13:13
iceyogra_: copying text into a snapped app is weird13:13
didrocksogra_: ok, which ppa? (if you prefer to do it yourself, feel free ;))13:14
ogra_didrocks, http://paste.ubuntu.com/23893526/13:14
ogra_didrocks, from https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial13:15
didrocksogra_: excellent! Thanks a lot :)13:15
ogra_(note that the pasted one is outdated, use the actual one from the PPA)13:15
didrocksyeah, I'll be able to find it, I'm sure :)13:17
jdstranddavidcalle: ping re security whitepaper (I asked a question probably after your eod on friday)13:35
zygajdstrand: hey14:11
jdstrandzyga: hey :)14:11
zygajdstrand: I'm working on the kernel bug and also on the string changes you suggested14:12
zygajdstrand: I think the outcome will be much safer, thanks for that!14:12
jdstrandzyga: gret! :)14:13
jdstrandgreat even!14:13
davidcallejdstrand: I'm on it today, pdf is live already14:19
jdstranddavidcalle: hi! :) ok, so is https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/ the correct url for the whitepaper? it is out of date, but the pdf it links to is up to date14:26
davidcallejdstrand: indeed, I've uploaded the new pdf, updating the page as we speak (will be live in a short moment)14:28
jdstranddavidcalle: ah, I see. ok, thanks! :)14:28
om26erwhat should I do if I want some feedback from the user once a snap is installed ? I am working on a selenium based twitter bot that is going to run on xvfb. For twitter login I need to request username/password from the user to login.14:46
om26eris there probably a way to run a script once a snap is installed ?14:46
mupPR snapd#2558 closed: snapstate: move refresh from a systemd timer to the inernal snapstate Ensure() <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2558>14:53
kirklandsergiusens: is that perhaps why my snap isn't showing up in the store?  because it's classicly confined?14:59
mupPR snapd#2744 opened: move configstate.Transaction stuff into configstate.transaction <Created by mvo5> <https://github.com/snapcore/snapd/pull/2744>15:01
stokachukirkland, snap find conjure-up works though it returns a bunch of results15:04
kirklandstokachu: can you "snap find hollywood"?15:04
stokachusnap find hollywood15:05
stokachuThe search "hollywood" returned 0 snaps15:05
stokachukirkland, is our snap published/public in the webui?15:05
kirklandstokachu: yes, it looks like it15:06
stokachukirkland, not sure if this helps but here is what mine looks like from the webui: http://imgur.com/a/pEiEp15:11
stokachukirkland, oh do you have a stable snap published?15:12
stokachui have at least one stable15:12
kirklandstokachu: ah, maybe that's it?15:13
kirklandstokachu: so, I need to change "grade: devel" to "grade: stable" in snapcraft.yaml?15:14
kirklandstokachu: rebuild, reupload?15:14
stokachukirkland, try just releasing it to stable channel from the webui15:15
stokachujdstrand, is kirkland's hollywood snap not showing up in the snap search results b/c it hasn't been approved?15:27
kirkland<jdstrand> 00:40:01> kirkland: done. approved but you'll need to release it15:28
kirklandI got that on Friday15:28
kirklandand then I did release it15:28
stokachukirkland, ah ok15:38
jdstrandstokachu: it is in beta and edge. 'stable' is the only channel 'snap find' will give results for15:38
jdstrandkirkland: fyi, I see 1.12 is uploaded but not released anywhere15:39
kirkland1 kirkland@x250:/tmp/sandbox.hwgfBlQv/hollywood/snapāŸ« snapcraft release hollywood 1 stable15:39
kirklandRevision 1 (classic) cannot target a stable channel (stable, grade: devel)15:39
kirklandnow that worked15:39
kirkland(bumped the rev)15:39
stokachukirkland, \o/15:40
jdstrandkirkland: you seem to have specified 'grade: devel' which means it will never go to stable15:40
jdstrandkirkland: ah, you fixed that in 1.1215:40
jdstrandand snap find now finds it15:41
stokachukirkland, haha nice snap15:42
qenghoWhat does hollywood do, kirkland?15:50
kirklandqengho: https://www.youtube.com/watch?v=rVMn3xk5mcY15:50
qenghoAh! I remember this.15:50
qenghoThis reminds me of a tool I remember from my early unix days, when I was just an egg. Our auditory processing is as good or better than visual attention. An app would convert network traffic into sound. You'd start it and maybe hear that something seems a little off today.15:55
cos-what's the trick to create a desktop launcher with snap? i have desktop: entry in app: but no icon appears in menu15:55
cos-a working example would be nice15:56
zygacos-: it's tricky, ask sergiusens16:04
cos-also having a desktop in setup/gui doesn't seem to work, as examplified here https://github.com/ubuntu-core/snapcraft-examples/blob/master/03-hello-world-desktop-devmode/setup/gui/hello-world-desktop.desktop16:04
ogra_cjwatson, hey ... we need some expert opinion ... in the core images we used to use a profile.d snippet to extend the PATH with /snap/bin (we do that in classic still), for remote ssh commands without login shell that didnt work, so we moved the /snap/bin to the global PATH in /etc/environment ... now it turned out that some tests actually use su ...16:04
mupPR snapd#2745 opened: cmd: add sc_must_stpcpy <Created by zyga> <https://github.com/snapcore/snapd/pull/2745>16:05
zygajdstrand: hey, could you please have a look at this pull request: ^^ this is the safe stpcpy we've discussed.16:05
ogra_cjwatson, i remember you being opposed to change ENV_SUPATH (and i'm slightly reluctant to touch login.defs at all) ... should we or should we not change it there ?16:06
zygajdstrand: my only comment was to perhaps use memmove just to be super paranoid safe16:06
ogra_cjwatson, or rather ... what would be the drawbacks16:06
cjwatsonogra_: just /etc/environment is supposed to work for su as well; this is basically https://wiki.ubuntu.com/OneTruePath16:06
kirklandstokachu: okay, we're there now :-)16:07
ogra_ah, i didnt find the wikipage16:07
cos-and for qt5 app should i have after: desktop/qt5, desktop-qt5 or qt5conf? all are used in different examples16:07
cjwatsonogra_: I don't think you should change it there, but rather you should chase down why su's use of pam_env apparently isn't working?16:07
stokachukirkland, cool man16:07
ogra_cjwatson, well, it seems it doesnt16:07
kirklandstokachu: thanks for your help16:07
cjwatsonogra_: I'm not arguing with that, but from the config file on my system it seems that it should16:07
stokachunp anytime16:07
cjwatsonogra_: so that seems worth tracking down rather than working around and forgetting16:07
ogra_ok, thanks16:07
mupPR snapcraft#1092 opened: meta: properly get the icon extension from splitted name <Created by 3v1n0> <https://github.com/snapcore/snapcraft/pull/1092>16:18
cos-sergiusens: i'd appreciate any help with creating a .desktop launcher. my current code is here https://github.com/vranki/siilihai-client16:24
ogra_cjwatson, hmm, are you actually sure su should use pam_env for PATH ? the manpage sounds like some vars wont be read from there http://paste.ubuntu.com/23894355/16:26
cos-hmm, maybe the used files should be in the git repository and having them in the build directory isn't enough.. i'll try recreating the package with files in git16:26
ogra_cjwatson, note the "Other" in there16:26
cjwatsonogra_: see /etc/pam.d/su16:28
cjwatsonI see no reason to assume the manual page is up to date with the intended PAM configuration :-)16:29
mupPR snapcraft#1093 opened: python plugin: do the right thing with classic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1093>16:54
=== petevg is now known as petevg_noms
stokachusergiusens, ^ will that fix classic install on trusty?17:17
elopioogra_: you are scheduled for the linaro open hours on feb 23th, 8am pacific time.17:18
ogra_elopio, ok, i'll add that to my calendar17:18
elopioChipaca: zyga: would you like to join them for an episode and talk about ubuntu core 101? it would be feb 16th.17:18
elopioogra_: thanks. Robert will send you an email with the details.17:19
Chipacaelopio, can i think about it?17:19
zygaelopio: yes, gladly17:19
elopioChipaca: yes, and you can also say no :) This is the thing: http://www.96boards.org/OpenHours/17:19
zygaelopio: can you please send me an invite? I forget everything otherwise :)17:19
elopiothanks zyga.17:20
ogra_elopio, huh, saying no is an option ?!?17:20
elopioogra_: it was an option for you last week. Not anymore :p17:20
elopiokgunn: are you around now? I'm not sure if you got my ping, maybe email is better.17:21
elopiojamiebennett: and this is the thing you signed up for: https://www.youtube.com/watch?v=P1_HjzcnJ-s17:22
kgunnelopio: what's up17:22
elopioyou will be the main panelist on the march 9th.17:22
kgunnabout to go for a run....but at least i got your most recent ping17:22
jamiebennettelopio: I did ;)17:23
jamiebennettogra_: is also going so maybe we can tag team17:23
elopiokgunn: hello! go and run. I'm sending you an email to see if you want to show the kiosk on linaro openhours and ubuntu testing days.17:23
kgunnah, elopio ok.... cc AlbertA ;)17:23
elopiowill do.17:24
elopiojamiebennett: ogra_: Robert said rsalveti will be in the panel too. I can only imagine the party afterwards :D17:25
ogra_elopio, lol17:25
ogra_and i know in which bar it will happen !17:25
zygaelopio: my pleasure :-)17:27
zygaelopio: lol :)17:27
ogra_hah, the lurker !17:28
zygarsalveti: hey :)17:28
zygarsalveti: how are you doing?17:28
rsalvetigood :-)17:28
rsalvetiwho are going to be at connect?17:29
zygarsalveti: I think only ogra_17:29
rsalvetihow are things at the snappy land :-)17:30
zygaconnect is in US so I cannot go :/17:30
rsalvetiogra_: oh! that would be awesome17:30
ogra_rsalveti, it will !!!17:30
ogra_zyga, huh ? budapest i thought ...17:30
zygarsalveti: reliable little by little17:30
zygaogra_: oh17:30
zygaogra_: the vegas thing confused me17:30
zygathen I could go17:30
zyga(if someone would want me there)17:30
ogra_i guess the US is dead territory for conferences for the next 4 years17:30
rsalvetihahah, indeed17:31
rsalvetiogra_: going to drive there?17:31
rsalvetidon't remember if you did that last time17:31
ogra_i did17:32
rsalvetiright, I had some good memories :-)17:32
zygaogra_: or 1617:32
ogra_but i largely gave up on cars ... so it would be rental or train ...17:32
zygaogra_: 4 + 4 then after the war with canada and mexico is over ;)17:32
ogra_its a lovely ride thogh ...17:32
ogra_zyga, if it is only canada and mexico, yeah17:32
rsalvetiget a new porsche17:32
ogra_nah, i still need to get rid of the three others :P17:33
zygaogra_: then china invades and all connects will be in china ;-)17:33
ogra_you mean "berlin - china" or "paris -china" ?17:33
zygaogra_: just bejning east, west, central, etc...17:33
ogra_lol ...17:34
zygaogra_: on the upside, aliexpres will ship locally17:34
zygafrom the moon :D17:34
ogra_apart from UK though ... because of brexit17:35
zygaI still wait fo brexit for electricity, to stop the immigration of electrons from mainland17:35
zygaUK could switch to 100VCD17:35
=== petevg_noms is now known as petevg
mupPR snapd#2712 closed: interfaces/builtin: refine the content interface rules using $SLOT <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2712>18:41
blackboxswsorry my bad. was search the responses in the irc term19:17
blackboxswwas searching*19:17
blackboxswwas looking for hints as to why "service snap" namespace in trusty doesn't seem to map to a given snap running snap.  For example, "sudo service snapd status" works on xenial, but not on trusty19:19
mupPR snapd#2746 opened: interfaces: remove some syscalls already in the default policy plus comment cleanups <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2746>20:10
mupPR snapd#2747 opened: interfaces/mount-observe: add quotactl with arg filtering (LP: #1626359) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2747>20:33
mupPR snapd#2748 opened: seccomp-support.c: add PF_* domains which can be used instead of AF_* <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2748>20:38
zygajdstrand: hey, still around?20:46
mwhudsonwtf, i think i've found a glibc bug20:48
zygamwhudson: hey20:49
zygamwhudson: long time, how are you?20:49
mwhudsonzyga: ok!20:49
mwhudsonzyga: well right now i am in a rabbit hole but otherwise :)20:49
zygamwhudson: what are you up to? do you need a garden elf assistant? :)20:50
mwhudsonzyga: i'll have a bug comment in a minute20:50
mwhudsonzyga: i hope you didn't say 'elf' there by accident20:51
zygasuch a versatile word :) works both ways20:51
mwhudsonoh heh i commented by email so i can't show it to you yet20:53
mwhudsonzyga: it will be here in a few minutes: https://bugs.launchpad.net/snapd/+bug/1657504/comments/1820:54
mupBug #1657504: asciinema 1.3.0 snap is segfaulting on 14.04 <Snapcraft:In Progress by sergiusens> <snapd:New> <https://launchpad.net/bugs/1657504>20:54
mcphailI could never get dlopen() to work in a snap I was making20:55
mwhudsonzyga: it's there now20:56
mwhudsonmcphail: a classic or strict snap?20:56
mcphailmwhudson: strict20:56
mwhudsonmcphail: probably something a bit different from this then, i think20:57
mcphailmwhudson: aah, OK20:57
zygamwhudson: oh, intereting20:57
zygamwhudson: looking20:57
zygaI was working on that part so very keen to get to the bottom ofthat20:58
mwhudsonzyga: the code in glibc is around here https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-load.c;h=a5318f9c8d1d42745a254479cf6bb1cd2acd516f;hb=HEAD#l203520:59
mwhudsonzyga: DT_RUNPATH is only like 15 years old, of course there are still loads of obscure bugs when you try to use it20:59
zygamwhudson: do you know if nss works by loading modules into the process or by doing IPC to something that loads the modules?20:59
mwhudsonzyga: it just calls dlopen21:00
mwhudsonthis is one of the reasons static linking with glibc don't work good21:00
mwhudsonzyga: https://sourceware.org/git/?p=glibc.git;a=blob;f=nss/nsswitch.c;h=0a65f6ad0c640ae144cbe9d7c2edf9d67e67a245;hb=HEAD#l35821:01
zygamwhudson: that makes sense, I recall a warrning from the linker when one does that to name resolution functions21:01
zygamwhudson: so what should we do to have libc load the nss modules from the core snap?21:02
mwhudsonzyga: fix glibc to look at DT_RUNPATH in the executable, i think21:02
mwhudsonzyga: which is of course going to be loads of fun21:02
mwhudsonzyga: you could also try turning off the flags that make ld emit RUNPATH vs RPATH21:03
zygamwhudson: and good fun of work21:03
zygafun kind of work :)21:03
mwhudsonwell at least you don't have to argue with mr drepper any more21:03
zygamwhudson: actually I don't know why I suggested to use the newer version of those flags21:03
zygamwhudson: for the initial experiment rpath worked just as well21:03
mwhudsonzyga: if you use RPATH, LD_LIBRARY_FLAGS is ignored21:04
zygamwhudson: but AFAIK we don't need LD_LIBRARY_FLAGS for classic snaps21:04
zygamwhudson: (for those that are linked properly)21:04
mwhudsonoh heh this dude found the same thing as me http://blog.qt.io/blog/2011/10/28/rpath-and-runpath/21:04
mwhudson(and i'd read that post before too)21:05
zygamwhudson: question: would it be possible to invoke the dnyamic linker to ask it to load an executable without rpath/dtrunpath?21:05
zygamwhudson: e.g. to load /bin/true from the core snap that is just vanilla /bin/true in an odd location21:05
mwhudsonzyga: i don't understand, sorry21:07
mwhudsonzyga: you don't feel like writing something that adds DT_RUNPATH (and edits the ELF interpreter) to all binaries in the core snap? :)21:08
mwhudson(i presume in strict snaps the core snap is available at both / and /snap/core/current ?)21:09
zygamwhudson: that's the problem actually, it's not21:09
zygamwhudson: and we want one core snap, not two (one for classic and one for strict confinement)21:09
zygamwhudson: in strict confinement core snap is / and you cannot read /snap/core/*21:09
mwhudsonzyga: ah21:09
mwhudsonzyga: fun times21:09
zygamwhudson: in classic confinememt core snap is /snap/core/* and you can read anything21:09
zygamwhudson: goal: make it possible to run stuff from the core snap in both cases21:10
zygamwhudson: I was thinking about having snap-exec run the dynamic linker (even patched one since it's the one from the core snap)21:10
mwhudsonzyga: don't see how that's possible21:10
zygamwhudson: and load the application with some fancy defaults21:10
mwhudsonsomething like that might work21:10
zygamwhudson: but that breaks down when we exec something from the core snap (e.g. we run bin/sh but then we run bin/ls)21:10
zygamwhudson: because then the system (wrong) linker gets used21:11
zygamwhudson: I don't know of a way to force "gimme that linker" somehow21:11
zygamwhudson: unless21:11
zygamwhudson: we do some hackery around exec in the libc that ships in the core snap21:11
zygamwhudson: then it might just work allright21:11
zygamwhudson: it'd be a simple case of path comparison, if starts with /snap -> use fancy linker mode21:11
zygamwhudson: crazy? certainly! possible? maybe21:12
mwhudsoncan you bind mount something over /lib/ld-linux.so.2?21:12
mwhudsonuh not that one21:12
zygamwhudson: no, because in confinement: classic mode we don't have a mount namespace so everything in the system would sere that21:12
zygamwhudson: we can but that's hurt us21:12
zygamwhudson: and distros would be looking at us carefully if we bind mount over /lib for eveyone to see just to run21:12
zygamwhudson: I think we need some linker work to make this play ball21:13
mupPR snapd#2749 opened: interfaces/default: allow mknod for regular files, pipes and sockets <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2749>21:13
mwhudsoni think so too21:13
zygamwhudson: at the very least to fix nss issue21:13
mwhudsonwell also this running /snap/core/bin/ls uses the host elf interp thing21:14
zygamwhudson: hmmm21:14
zygamwhudson: yes21:14
zygamwhudson: that's true21:14
mwhudsonthis is all very confusing21:14
zygamwhudson: unless we never allow that to happen21:14
zygamwhudson: remember that we control all entry points21:14
mwhudsonzyga: you mean, just don't let classic snaps exec things from the core snap?21:14
zygamwhudson: snap-run -> snap-exec: we can run a patched dynamic linker at that stage21:14
zygamwhudson: exec: we can use a patched glibc that uses an alternate linker if the target is in the core snap21:15
zygamwhudson: I think we should not restrict what classic confinement snaps can run21:15
zygamwhudson: it would limit their usefunless heavily IMHO21:15
mwhudsonyeah it's a pretty blunt instrument21:15
jdstrandzyga: hey, yes21:16
zygamwhudson: do you see any alternative ideas?21:16
zygajdstrand: hey :)21:16
zygajdstrand: I just commented on your PR :)21:16
mwhudsonzyga: seccomp-bpf? :)21:16
mwhudsonzyga: anyway, i think the nss issue is easier than the interpreter issue21:17
zygamwhudson: hmmm, curious21:17
mwhudsonzyga: "just" patch libc (well libdl) in the core snap to respect RUNPATH in the executable, like the docs say21:17
zygamwhudson: how would that work? we'd attach a seccomp profile that patches exec?21:17
mwhudsonzyga: yeah21:17
mwhudsonzyga: i have no idea if that's easily possible21:18
mwhudsoner -easily21:18
mwhudsonzyga: i worry about statically linked go binaries :)21:18
zygamwhudson: but taht profile carries across exec right? would it not clash if someone wanted to run something that already uses seccomp for other things?21:18
zygamwhudson: oh, interesting21:18
zygamwhudson: don't those use their own name resolver stack?21:18
mwhudsonzyga: for the elf interpreter stuff i mean21:19
zygajdstrand: if you could give me some feedback on the sc_must_stpcpy branch I would really appreciate it21:19
zygamwhudson: mmmm21:19
zygamwhudson: wait, what's the problem there? there are no libaries to cause issues21:19
zygamwhudson: and and golang's dlopen just needs to be fixed somehow (if broken)21:19
zygaI must be missing something21:20
zygajdstrand: is that branch changing our dependency on base seccomp version in any way? (both in kernel and in the userspace)21:20
mwhudsonzyga: it's possible i am21:20
mwhudsonzyga: this is all very confusing, and you've spent longer thinking about it than i21:21
zygamwhudson: (offtopic, I find it funny that I just opened IRC by accident and joked about "garden elf" and here we are talking about this issue that's currently also close to my heart as I was working with sergiusens earlier trying to figure out what's going on)21:21
zygamwhudson: (any) statically compiled binary will work OK (or not) but is beyond our control, if it includes a dynamic linker inside we also have no way to influence it21:22
zygamwhudson: I was thinking about extending the auxilliary vector to set a bit that indicates a given process uses classic confinement21:23
zygamwhudson: and that would change how linker behaves21:23
blackboxswhi folks, question out of left field. I'm on trusty, how do I check the status of the snapd process and my snaps. I was accustomed to using systemd w/ "service snapd status" and "service snap.<snap_name> status" on xenial.21:24
mwhudsonzyga: and what behaviour would it change ?21:24
zygamwhudson: I think we could use it to change default search path21:24
zygamwhudson: my goal would be to leverage that to have pre-compiled software (e.g. debs) work as classic confinement snaps21:25
blackboxswI see snapd package on trusty pulls in systemd as a dependency, I'm just not sure how that shakes out as far as checking ths snap processes via tools like services, initctl  etc. I *could* check ps easily enough, but I wondered what expected behavior is.21:25
mwhudsonzyga: oh, so you wouldn't need to set DT_RUNPATH in the binaries in a classic snap?21:25
zygablackboxsw: on 14.04 we have a deputy systemd21:25
mwhudsonzyga: just the elf interpreter ?21:25
zygamwhudson: exactly21:25
zygamwhudson: because we probably cannot just (not sure) easily rewrite a random executable to have it "gain" runpath and a different dynamic linker path21:26
mwhudsonwell not even the elf interpreter, because you jam a custom interperter in via snap-exec21:26
zygamwhudson: the dynamic linker path is also problematic but if we do it upstream it could work elsewhere too21:26
zygamwhudson: yes, that's true21:26
zygablackboxsw: and you should be able to use regular systemd commands to control services21:27
mwhudsonand you'd also have a hook in exec that does if exe_path.startswith("/snap/core"): jam_custom_interp_in()21:27
zygablackboxsw: there might be some bits missing; I don't know if journald is wired, for example21:27
zygamwhudson: yes21:28
mwhudsonzyga: well sounds crazy, and not inherently impossible21:28
zygamwhudson: the idea with the extra bit in auxv is to have clean transitions from snaps to classic world21:28
zygamwhudson: but perhaps we can do that with snap-exec each time and this is not required21:28
zygamwhudson: (all transitions are out of snap world, snap-exec brings us back)21:29
mwhudsonzyga: not if the classic snap just invokes /snap/core/bin/python3 directly?21:29
zygamwhudson: that's true, I forgot about side-stepping the apps system21:30
zygamwhudson: then we need patched glibc21:30
zygamwhudson: or seccomp-bfp21:30
zygamwhudson: I think that we will either 1) spec this and JFDI or 2) reconsider classic confinement21:30
zygamwhudson: as right now the edges feel pretty sharp :/21:31
blackboxswzyga, thanks for the suggestion. yeah, what I'm seeing from trusty-proposed seems like it's missing a little bit of glue. I'll try digging a bit more, but running "service snapd status"  errors with "unrecognized service" though I see /lib/systemd/system/snapd.service defined21:31
zygablackboxsw: I think you want to talk to tvoss, he was working on this feature21:32
mwhudsonzyga: yeah, in some ways the "mixed world" of classic snaps is trickier than isolated snaps21:32
zygamwhudson: if we do the magic right it will seem easier21:33
zygamwhudson: but I totally agree with what it is today21:33
blackboxswgood reference zyga thanks will continue the conversation with him.21:34
tvossblackboxsw: o/21:35
blackboxswtvoss, isn't it 22:35?21:36
sergiusensmwhudson: zyga well I fixed all env var leaking for classic snaps (even PATH), use a little shebang trick to chose the right interp and added a way to provide your own python in stage for the plugin to use21:36
tvossblackboxsw: so for snapd itself and services from snaps, systemctl should do the right thing21:36
tvossblackboxsw: yup, it's 22:3521:36
tvossblackboxsw: so systemd is not running as pid 1 on trusty, upstart is still the init system21:37
tvossblackboxsw: so using sudo service will end up querying upstart, instead of systemd21:37
blackboxswtvoss, ahh got it! thanks, looks like I needed "sudo" on trusty too21:37
blackboxswwithout sudo it gives things like "No such interface" etc.21:37
tvosshmmm, I can give that a spin tomorrow my morning, on my tablet right now21:38
tvossI'll take a note, thanks for testing it out21:38
blackboxswthanks for the response. tvoss. solved my initial hurdle21:39
tvossblackboxsw: cool, later then :)21:39
sergiusensmwhudson: if it helps http://paste.ubuntu.com/23895943/21:40
mupPR snapd#2750 opened: interfaces/default: don't allow TIOCSTI ioctl <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2750>22:16
mupPR snapcraft#1091 closed: tests:  add ubuntu user to sudoers on every adt platform  <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1091>22:34

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!