| === kallisti6 is now known as kallisti5 | ||
| === chihchun_afk is now known as chihchun | ||
| Sargun | Can you run a snap "anonymously" (like a Docker container) | 07:08 |
|---|---|---|
| === faenil is now known as faenil_ | ||
| zyga | o/ | 07:53 |
| === faenil_ is now known as faenil | ||
| ogra_ | Sargun, can you elaborate what that means ? snap services usually run as root ... snap app binaries as the user that starts them both in a controlled environment that they can not break out of | 08:27 |
| qengho | ogra_: a lot of sevices really hate running as root. I think it would be nice if the system reserved a nonroot uid for such cases. E.h., snapd registers a user, and puts that uid with some name in the shared /etc/passwd file, or something. | 09:24 |
| qengho | No, e.h is not a merger of e.g. and meh. | 09:25 |
| pmp | for iio-usage I have a snap which will read-only-access sysfs, which is prohibited by snapd | 09:28 |
| pmp | Is there an interface for it or should I file a bug requesting an interface? | 09:28 |
| pmp | How should sysfs-accesses be handled? Typical IIO-applications will also want to write to sysfs, for example to enable a device or to install a timer. | 09:29 |
| Sargun | ogra_: have a use case where developers can anonymously deploy apps throughout my system | 09:45 |
| Sargun | imagine kubernetes, or Docker swarm | 09:45 |
| Sargun | So, Ideally I'd like to run these as processes | 09:45 |
| Sargun | independently from snapd | 09:45 |
| === hikiko is now known as hikiko|afk | ||
| popey | dpm: I filed this issue with sergiusens' qt5conf, but yours is affected too.. https://github.com/sergiusens/qt5conf/issues/3 (basically we shouldn't have "cd" in any launchers IMO) | 10:45 |
| dpm | thanks popey. I'll look at it during the playpen tomorrow. I just want to make sure removing the 'cd' does not break the Qt apps that are currently using the launcher | 10:50 |
| popey | dpm: cool | 10:51 |
| ogra_ | hmm | 11:12 |
| ogra_ | why is node-engine not respected in my snapcraft.yaml | 11:12 |
| ogra_ | oh, it is | 11:24 |
| ogra_ | seems nw.js is simply built statically against node 6.2.2 | 11:24 |
| === hikiko|afk is now known as hikiko | ||
| sergiusens | good morning | 13:23 |
| sergiusens | hey kyrofa mind taking a look at https://github.com/ubuntu-core/snapcraft/pull/608 ? | 13:23 |
| kyrofa | sergiusens, good morning! Sure. Actually, would you mind taking a look at https://github.com/snapcore/snapd/pull/1340 ? Make sure it matches up with what you're thinking for snapcraft | 13:24 |
| didrocks | kyrofa: does source-subdir works for you? I'm unsure I'm using it badly or anything, but it seems to me that build/ still reference the root dir and not a subdir | 13:27 |
| didrocks | (despite what the help says) | 13:27 |
| didrocks | also, unkown source-subdir doesn't trigger anything, it's like if the property wasn't read | 13:28 |
| kyrofa | didrocks, it depends up the plugin. I don't think go handles it well, for instance | 13:30 |
| kyrofa | depends on* | 13:30 |
| sergiusens | kyrofa didrocks the go plugin, from its `help` does not mention it uses the sources implementation from the base plugin | 13:32 |
| kyrofa | sergiusens, ah! Good point | 13:32 |
| kyrofa | didrocks, but yeah, try the make plugin | 13:33 |
| sergiusens | maybe this has become a defacto expected core functionality though | 13:33 |
| sergiusens | and we should consider moving source handling to the core | 13:33 |
| didrocks | sergiusens: kyrofa: hum, I'm using the make plugin | 13:35 |
| kyrofa | didrocks, hmm, let me investigate | 13:35 |
| didrocks | kyrofa: want an example I'm expecting to work from the help? | 13:36 |
| kyrofa | didrocks, sure | 13:36 |
| didrocks | kyrofa: http://paste.ubuntu.com/17969379/ | 13:36 |
| didrocks | and here parts/gtk/build/ == parts/gtk/src (where I expect from --help parts/gtk/build/ == parts/gtk/src/gtk) | 13:37 |
| kyrofa | didrocks, uh oh... there might be a regression here | 13:39 |
| didrocks | ah, I'm not crazy :) | 13:39 |
| kyrofa | didrocks, indeed, parts/gtk/build should contain everything from the src if my memory serves | 13:39 |
| didrocks | also, try to put foo as source-subdir | 13:40 |
| didrocks | no complain, nothing | 13:40 |
| kyrofa | didrocks, but the plugin's builddir should be in the subdir | 13:40 |
| didrocks | yeah | 13:40 |
| didrocks | that's what the --help says | 13:40 |
| didrocks | kyrofa: also, a fun thing with that, noted that I have to define a make parameter? | 13:40 |
| didrocks | it's because symlinks are copied as such | 13:40 |
| didrocks | (and when they go out of the src dir… :p) | 13:40 |
| didrocks | ok, that's an edge case, but still ;) | 13:41 |
| kyrofa | didrocks, yeah I'm not sure why you're having to do that. Why can't it build in the builddir? | 13:41 |
| didrocks | kyrofa: look at the source in gtk/ | 13:42 |
| didrocks | it's a symlink to common/ | 13:42 |
| didrocks | and so, that file, once copied in builddir, becomes a dangling symlink | 13:42 |
| didrocks | (you can try it with the snapcraft.yaml in gtk/ dir) | 13:43 |
| kyrofa | Ah, I see | 13:47 |
| kyrofa | didrocks, wait, no, I'm being dumb. This seems to work okay here | 13:59 |
| kyrofa | didrocks, including the symlink being okay | 13:59 |
| didrocks | kyrofa: symlink or source-subdir? | 14:00 |
| didrocks | kyrofa: it does work because of build/ isn't build/gtk | 14:00 |
| didrocks | but once it's build/gtk, then ../common doesn't exist | 14:00 |
| didrocks | (check the snapcraft.yaml in gtk/ directory for instance) | 14:00 |
| kyrofa | didrocks, using what you gave me (and removing the make-params) works | 14:01 |
| kyrofa | didrocks, parts/gtk/src is copied into parts/gtk/build, then the plugin runs out of parts/gtk/build/gtk | 14:02 |
| didrocks | kyrofa: hum, I'm on 2.11, it doesn't here | 14:02 |
| kyrofa | didrocks, which I realize now is actually different than the docs for source-subdir, oops | 14:02 |
| didrocks | yeah | 14:03 |
| kyrofa | didrocks, but it was done that way for instances like this, where you needed to build in a subdir but you still needed the rest of the project | 14:03 |
| didrocks | hum, you're right, it does work because it's different frmo the doc :) | 14:03 |
| didrocks | yeah | 14:03 |
| kyrofa | didrocks, sorry about that, I fixed that bug ages ago but apparenty never updated the docs | 14:04 |
| didrocks | kyrofa: no worry, at least, yeah, it does work and fix the symlink issue (which only appear when snapcraft.yaml is in gtk/) | 14:04 |
| didrocks | but I guess as it's referencing something "above the top dir for snapcraft.yaml" that makes sense | 14:05 |
| didrocks | (and my Makefile copes with both) | 14:05 |
| kyrofa | didrocks, indeed, that would make sense | 14:05 |
| didrocks | kyrofa: ok, so only the help needs to be modified :) | 14:06 |
| kyrofa | didrocks, indeed | 14:06 |
| didrocks | thx! | 14:06 |
| kyrofa | didrocks, thank you! | 14:06 |
| === olli__ is now known as olli | ||
| elopio | fgimenez: can you send me the bots credentials please? | 14:14 |
| sergiusens | elopio hey, can you look at 608 again | 14:20 |
| sergiusens | elopio I went fixture crazy just to make you happy! | 14:20 |
| elopio | sergiusens: that sounds good :) Let me see. | 14:21 |
| dholbach | seb128, we have a bug in https://github.com/ubuntu/snappy-playpen/tree/master/atom where the menu is not exported - do you know of the problem? | 14:36 |
| didrocks | dholbach: we are just starting looking at it together (as planned ;)) | 14:37 |
| dholbach | didrocks, I was just wondering if there was a bug for it already | 14:37 |
| didrocks | dholbach: we will file one if we can't sort it out today I guess | 14:38 |
| dholbach | didrocks, thanks - if the issue persists, it'd be good to add it to https://github.com/ubuntu/snappy-playpen/wiki/Known-issues | 14:38 |
| didrocks | yep | 14:38 |
| didrocks | Not that I completed README.md with it already | 14:39 |
| dholbach | thanks a lot didrocks | 14:40 |
| seb128 | dholbach, why did you set that gsettings bug to fix released? it's not, the update is still blocked in y-proposed | 14:44 |
| seb128 | the bugs are going to autoclose when it migrates | 14:44 |
| dholbach | seb128, oh? | 14:44 |
| seb128 | if you want to see those closed get somebody to fix their autopkgtest :p | 14:44 |
| dholbach | seb128, sorry, I thought the update had landed already :) | 14:44 |
| seb128 | dholbach, no worry | 14:48 |
| sergiusens | elopio ok, one more look | 14:50 |
| === willcooke_ is now known as willcooke | ||
| sergiusens | elopio so wrt the milestone, where are we on the other tasks? | 15:03 |
| elopio | sergiusens: let me move my "in progress" ones to 2.13. And after the search lands, we are good to go. I'm going to see which ones are still missing the template. | 15:04 |
| jdstrand | roadmr: hi! would you mind pulling r687 at some convenient time? | 15:09 |
| roadmr | jdstrand: sure thing! | 15:09 |
| jdstrand | roadmr: it isn't super-critical | 15:09 |
| jdstrand | thanks! :) | 15:09 |
| fgimenez | elopio, sure one sec | 15:10 |
| sergiusens | elopio oh, where is that script you had for me? | 15:19 |
| elopio | sergiusens: only tested in staging, so let me know if you see bugs. https://github.com/elopio/snapcraft/blob/launchpad_scripts1/scripts/launchpad/add_series.py | 15:20 |
| seb128 | dholbach, atom fails to build for me, http://paste.ubuntu.com/17974945/ | 15:38 |
| dholbach | cwayne, ^ | 15:38 |
| seb128 | didrocks, ^ mentioning it as well | 15:38 |
| elopio | kyrofa: I think there's something wrong here: https://github.com/ubuntu-core/snapcraft/pull/580 | 15:44 |
| elopio | primed_dependencies is only set, never read. | 15:44 |
| kyrofa | elopio, heh, sergiusens pointed that out as well. I saved it in primed_dependencies to serve as both documentation and in case we ended up needing to track them, but indeed it's not used. The elsif is the real bugfix there | 15:46 |
| kyrofa | elopio, the fact that both of you pointed that out, however, shows that it does _not_ serve as decent documentation | 15:46 |
| elopio | kyrofa: ahh, I see. | 15:46 |
| elopio | yes, a would have been nice there. | 15:46 |
| kyrofa | elopio, should I just skip those instead of keeping track of them? | 15:47 |
| kyrofa | Oh, it's already merged, meh | 15:47 |
| elopio | kyrofa: I think so. Instead of an assignment, put a comment. But yeah, it might surprise us later but it's ok now. | 15:48 |
| kyrofa | elopio, I couldn't come up with a test case for why tracking them might be useful. I'll give that some further thought | 15:48 |
| kyrofa | I don't think it is, though | 15:48 |
| === devil is now known as Guest9208 | ||
| elopio | sergiusens: kyrofa: I don't like this one: https://bugs.launchpad.net/snapcraft/+bug/1596114 | 16:03 |
| ubottu | Launchpad bug 1596114 in Ubuntu Yakkety "adt, cannot snapcraft clean without remote parts when in use" [Undecided,New] | 16:03 |
| elopio | we need a valid yaml and up-to-date cache in order to clean. Isn't there some fallback we can do? | 16:03 |
| kyrofa | Hmm | 16:03 |
| elopio | maybe fail if we are trying to clean a specific step or part, but delete everything if no argument is passed? | 16:04 |
| kyrofa | Honestly clean could improve a bit by doing exactly that. It would really speed up as well | 16:04 |
| kyrofa | elopio, please make a bug, I'll take that one | 16:04 |
| sergiusens | kyrofa elopio yeah, not so great, but it wouldn't really hit users, no one really cleans before attempting to build and your are guided into the right direction if you try to build with missing defined parts | 16:09 |
| elopio | kyrofa: https://bugs.launchpad.net/snapcraft/+bug/1596596 | 16:09 |
| ubottu | Launchpad bug 1596596 in Snapcraft "in order to clean, the snapcraft.yaml has to be valid and the parts cache up-to-date" [Undecided,New] | 16:09 |
| sergiusens | clean can just skip mentioned parts that are undefined | 16:09 |
| dholbach | all right - I call it a day - see you all tomorrow! | 16:10 |
| sergiusens | elopio kyrofa what worries me more though is renaming a part and losing all knowledge of its existence | 16:10 |
| elopio | sergiusens: It hits me often :) But my workflow is not too smart, I agree there. | 16:10 |
| elopio | bye dholbach ! | 16:10 |
| dholbach | bye elopio :) | 16:10 |
| sergiusens | elopio kyrofa ie; do a snapcraft prime, remove a part and all your things from the remove part are still staged | 16:10 |
| sergiusens | until you clean all | 16:11 |
| kyrofa | sergiusens, yeah very true | 16:11 |
| kyrofa | sergiusens, how could we improve that? | 16:11 |
| sergiusens | kyrofa we need to track outside of the part and track the full yaml | 16:12 |
| sergiusens | and/or | 16:12 |
| elopio | that sounds like a good bug to report too. Go for it sergiusens :) | 16:13 |
| sergiusens | as in "these parts existed on the last run" | 16:13 |
| kyrofa | Yeah sounds like a good bug | 16:17 |
| kyrofa | I like those papercut ones | 16:17 |
| elopio | joc_: I saw you adding parts to the wiki. Heads up that with 2.12, the source page changes: https://bugs.launchpad.net/snapcraft/+bug/1594976 | 16:21 |
| ubottu | Launchpad bug 1594976 in Ubuntu Yakkety "Use new saved endpoint for wiki parts" [Undecided,New] | 16:21 |
| joc_ | elopio: thanks for the heads up, i saw some chat earlier about it :) | 16:22 |
| joc_ | elopio: i'll have another go, this time with the new infrastructure if can get the plainbox plugin to land | 16:23 |
| joc_ | elopio: all tests have passed btw ;) | 16:24 |
| elopio | joc_: nice! :) | 16:25 |
| elopio | sergiusens: all bugs ready. I suppose you will need next a script that marks all the bugs in yakkety as commited, and then released. That sounds easy to do while I wait for the SRU. | 16:25 |
| dtzWill | Read through lots of the documentation on snaps, parts plugins interfaces... this whole thing looks really useful and exciting! | 16:40 |
| sergiusens | elopio no, that is automatic | 16:41 |
| sergiusens | elopio what I would like is for the script to add the milestone to xenial | 16:42 |
| dtzWill | Unfortunately looking at package list I'm seeing via 'snap find' it seems things are still early in terms of developer buy-in :(. Read that firefox was going to use .snap, are there other indications/plans for more software to be included/shipped this way? | 16:42 |
| dtzWill | (regardless of the answer to my question, seriously GJ on all the parts--it's like nix for the real world lol :P) | 16:43 |
| elopio | sergiusens: I don't understand that one. Didn't that script already add all the bugs to xenial too? | 17:00 |
| sergiusens | elopio yes, but it doesn't add the xenial milestone | 17:00 |
| sergiusens | elopio as in https://bugs.launchpad.net/snapcraft/+bug/1596114 | 17:00 |
| ubottu | Launchpad bug 1596114 in Ubuntu Yakkety "adt, cannot snapcraft clean without remote parts when in use" [Undecided,New] | 17:00 |
| sergiusens | elopio the task xenial there has no milestone | 17:01 |
| elopio | sergiusens: that's something like xenial-updates, right? | 17:01 |
| sergiusens | elopio I just added it now. It doesn't | 17:01 |
| elopio | let me see if I can get something similar in staging. | 17:01 |
| sergiusens | elopio it is trivial and not important or required though | 17:01 |
| elopio | sergiusens: it | 17:01 |
| elopio | 's good to automate it all anyway. | 17:01 |
| sergiusens | kyrofa elopio https://github.com/ubuntu-core/snapcraft/pull/610 | 17:05 |
| sergiusens | dtzWill yes, it is early days; these things do take time | 17:06 |
| dtzWill | okay, awesome! No worries there, understood. Hoping to pitch this to my team, scrounging for data/confirmation about its use and future :). | 17:08 |
| dtzWill | thanks for the response :). | 17:08 |
| sergiusens | dtzWill well it is in the latest ubuntu lts release and will be the best way to deliver the latest and greatest | 17:19 |
| sergiusens | dtzWill if there is anything stopping you today that is not a "by design" limitation, we will surely look into it; heck even a design limitation if well thought out can be looked into to or reasoned out | 17:20 |
| dtzWill | honestly only 'problem' I foresee is some vague "it's not practical" arguments that aren't technically founded as much as "until other people do it, it might be risky/untested/bad in ways we don't know".... but AFAICT this'll fit our needs technically just fine! :) | 17:36 |
| dtzWill | but I'll let y'all know if that's not the case or if we get stuck in some way :). | 17:36 |
| ogra_ | kyrofa, sergiusens, is there any way to change permissions of a file via the copy plugin ? | 18:13 |
| kyrofa | ogra_, no, just a straight copy right now | 18:14 |
| ogra_ | sad ... | 18:14 |
| kyrofa | ogra_, what is your use-case? | 18:14 |
| sergiusens | ogra_ it is copy, not `install` ;-) | 18:14 |
| * ogra_ has an upstream tarball that ships the main binary with 0600 permissions ... | 18:15 | |
| ogra_ | inside the snap that is then root owned ... | 18:15 |
| ogra_ | so i cant exec it | 18:15 |
| elopio | sergiusens: maybe this: http://paste.ubuntu.com/17984723/ But I can't even test it in staging. | 18:20 |
| plars | So, I'm trying to get snapd working with dragonboard, but ubuntu-core doesn't want to install | 18:27 |
| plars | https://www.irccloud.com/pastebin/Gb910zTh/ | 18:28 |
| sabdfl | hiya | 18:37 |
| sabdfl | oh-hi-thar-snappy | 18:37 |
| kyrofa | Hey sabdfl, welcome :) | 18:41 |
| sergiusens | kyrofa elopio give me 2 | 18:46 |
| niemeyer | plars: That should have been fixed by now.. what's your version of snapd? | 18:54 |
| plars | niemeyer: 2.0.2 | 18:55 |
| plars | niemeyer: that seems to be the most recent available in the archive for arm64 | 18:55 |
| niemeyer | That's pretty old | 18:56 |
| niemeyer | Can you please try with 2.0.9? | 18:56 |
| plars | niemeyer: sure, do we have a build of 2.0.9 somewhere already for snapd? | 18:57 |
| plars | niemeyer: or is there a reason why the package in the archive is so old for it? | 18:57 |
| niemeyer | plars: Suspect it's autopkgtests not quite working as they should, which is something we're working on | 18:58 |
| plars | hmm, looking at lp, it should be there | 18:58 |
| plars | maybe updates isn't enabled on this image, let me check | 18:58 |
| plars | yep, that's it | 18:59 |
| plars | thanks | 18:59 |
| niemeyer | plars: Nice, np | 19:03 |
| kyrofa | sergiusens, all of a sudden cla-check doesn't build anymore. It doesn't seem to have anything to do with snapcraft as I tried all the way back to 2.9 | 19:46 |
| kyrofa | sergiusens, it hasn't changed since I published it a few days ago. Can you try to build it and tell me if it's failing for you? Quite baffling | 19:47 |
| kyrofa | Wait... it just worked. What the... | 19:49 |
| sergiusens | kyrofa good ;-) | 19:56 |
| sergiusens | or not ... :-P | 19:56 |
| elopio | cprov: travis tests are failing in register with 429, too many requests. | 19:59 |
| cprov | elopio: just started ? | 20:00 |
| elopio | cprov: I can add a sleep, but I would need to know how ofter are we able to register. | 20:00 |
| elopio | cprov: I don't think so. I have just added the debug to the test, but I think the same was happening friday. | 20:01 |
| cprov | elopio: let me check the current settings. Are you targeting staging, right ? | 20:01 |
| elopio | cprov: yes. But I also want to enable production tests soon. | 20:01 |
| cprov | elopio: okay, right back to you with the values. | 20:02 |
| zyga | tyhicks: hey | 20:02 |
| zyga | tyhicks: do you have a second? | 20:02 |
| tyhicks | zyga: hi | 20:04 |
| zyga | tyhicks: hey, I'm thinking about safe_mount patches by Serge Hallyn | 20:07 |
| zyga | tyhicks: it seems that Serge doesn't work for canonical anymore, do you know if those patches for lxd were written at the time he did? | 20:08 |
| tyhicks | zyga: yes, he and I worked on that solution together when he was working for Canonical | 20:09 |
| zyga | ah, thanks | 20:09 |
| zyga | I was thining that I can reuse that code with few modifications but I was worried about the licensing | 20:09 |
| zyga | thank you | 20:09 |
| tyhicks | zyga: note that I pointed out some unanswered questions in the original PR | 20:09 |
| tyhicks | zyga: will the snap author or the user launching the snap have control of any components in the src or dst paths? | 20:10 |
| tyhicks | zyga: if so, the safe_mount() solution (or something like it) will be needed | 20:10 |
| zyga | no | 20:10 |
| zyga | all of those paths are under our control entirely | 20:10 |
| zyga | well | 20:11 |
| tyhicks | :) | 20:11 |
| zyga | actually, that's not true | 20:11 |
| zyga | so we have ultimate control to ensure security but the snap can construct any symlink internally | 20:11 |
| tyhicks | right | 20:11 |
| zyga | I think we still want something similar to the path traveral code | 20:11 |
| zyga | that bails out on symlinks | 20:11 |
| zyga | (or maybe not bails out entirely but is more considerate) | 20:12 |
| zyga | though I don't quite know what the attack vector there might be given that this code runs after pivot_root | 20:12 |
| tyhicks | so they could symlink to some system directory and, without the safe_mount() logic, snap-confine would bind mount over an unintended location | 20:12 |
| tyhicks | hmm | 20:12 |
| zyga | an after unshare(CLONE_NEWNS) | 20:12 |
| tyhicks | good point | 20:13 |
| zyga | so technically, yes | 20:13 |
| tyhicks | are you sure that's true? | 20:13 |
| zyga | they can do "nasty" things | 20:13 |
| zyga | yes | 20:13 |
| zyga | 100% positive | 20:13 |
| zyga | ah, wait | 20:14 |
| zyga | it's not true but it should be | 20:14 |
| * zyga moves the call around | 20:14 | |
| zyga | after 1.0.34 I'll drop some ifdefs | 20:14 |
| zyga | so code will be easier to follow | 20:14 |
| zyga | (dead code will go away) | 20:15 |
| tyhicks | ok | 20:15 |
| zyga | I also wrote a few integration tess | 20:15 |
| zyga | tests*, I don't know if you saw those | 20:15 |
| zyga | if you have ideas on things that should be tested please suggest some, it is realy easy to write real integration tests now | 20:15 |
| tyhicks | I haven't seen the tests yet | 20:18 |
| zyga | https://github.com/snapcore/snap-confine/pull/51/files#diff-7d317bce59e92358d0d5f17f49606cd6 | 20:19 |
| zyga | (though please click and see various .yaml files, the link is not perfect) | 20:19 |
| zyga | all tests pass :) | 20:20 |
| tyhicks | those are nice and easy | 20:20 |
| zyga | tyhicks: we don't have coverage out of those but it's better than nothing | 20:23 |
| zyga | and those are real confine, non-test executables | 20:23 |
| zyga | out of the package | 20:23 |
| zyga | tyhicks: do you think I should port the safe_mount patches? | 20:29 |
| tyhicks | zyga: I was having trouble following you | 20:31 |
| tyhicks | zyga: you said that "technically, yes, they can do 'nasty' things" | 20:31 |
| tyhicks | zyga: is that not true? | 20:32 |
| zyga | tyhicks: I'm sorry, I said "nasty" ironically, because it was not something that exists on the outside anyway | 20:32 |
| tyhicks | zyga: ok, let me look at the branch where you moved the code around and see the ordering | 20:32 |
| zyga | if you think there is a risk that still applies I will use the safe mount approarch | 20:33 |
| zyga | better safe than sorry | 20:33 |
| zyga | I'm just looking for guidance | 20:33 |
| zyga | I wonder how apparmor and bind mounts combine | 20:34 |
| zyga | mmm | 20:34 |
| tyhicks | apparmor mediates mounting | 20:34 |
| tyhicks | because you can bind mount things around and trick the policy | 20:35 |
| zyga | right | 20:35 |
| zyga | bit after the bind mount is done, apparmor doesn't see "through it" | 20:35 |
| zyga | it's not like a symlink where apparmor sees the truth | 20:35 |
| tyhicks | correct | 20:35 |
| tyhicks | zyga: the pivot_root() is only called on classic distros | 20:39 |
| zyga | yes | 20:40 |
| zyga | tyhicks: pivot_root is only used to ensure consistency with all-snap systems | 20:43 |
| tyhicks | ok | 20:44 |
| zyga | (and so that we don't have to rely on the layout of the host filesystem) | 20:44 |
| tyhicks | zyga: that means we're relying on unshare(CLONE_NEWNS) to protect against any bind mount attacks, right? (assuming that we don't do safe_mount()) | 20:45 |
| zyga | yes | 20:45 |
| zyga | again, if you feel that we should do safe_mount, I'll do it | 20:45 |
| tyhicks | zyga: understood - I'm reviewing the changes you've made and thinking through the possibilities | 20:48 |
| zyga | thanks! | 20:49 |
| aatchison | Morning folks | 20:54 |
| zyga | aatchison: hey | 20:55 |
| aatchison | I was wondering who sergiusens did this "stage: - -usr/lib/python2.7/dist-packages/sphinxbase/*" What's the signifier of using two dashes? | 20:56 |
| aatchison | *why | 20:56 |
| zyga | - is a list | 20:57 |
| zyga | and 2nd - is "exclude" | 20:57 |
| zyga | so a list containing one element that excludes usr/lib/python/... | 20:57 |
| aatchison | oh! | 20:57 |
| aatchison | That's why it's not included :S | 20:57 |
| aatchison | lol, thanks | 20:57 |
| sergiusens | elopio adt passed for yakkety on amd64; pushing to xenial now :-) | 20:58 |
| LinuxGuy2020 | I really want to try and make some snap packages but so far it seems over my head. I'm not wanting to do anything crazy, just take already available debs from a given repository or ppa and turn it into a snap. I have no clue of what I have to put into the yaml file for that. Is there a easy guide for this thats not so cryptic for a non-developer to follow? | 20:59 |
| chrisatlee | hi! I'm looking for tips on packaging an app that uses gtk | 21:10 |
| zyga | LinuxGuy2020: not sure if you want to do that if you're not a developer, some things can get confusing; try to snap something trivial first | 21:10 |
| chrisatlee | hitting similar errors as https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1584357/comments/4 | 21:10 |
| zyga | LinuxGuy2020: do snapcraft init | 21:10 |
| ubottu | Launchpad bug 1584357 in snapcraft (Ubuntu) "Snappy GTK applications" [Undecided,Confirmed] | 21:10 |
| LinuxGuy2020 | zyga: Im not publishing for other people. Its just for my own personal use for now. | 21:11 |
| zyga | LinuxGuy2020: get one app written (apps are what is runnable from a snap) | 21:11 |
| zyga | LinuxGuy2020: then add one part that uses stage-packages to bring the debs you want inside | 21:11 |
| zyga | LinuxGuy2020: there are examples like that in snapcraft | 21:11 |
| zyga | LinuxGuy2020: sure | 21:11 |
| zyga | chrisatlee: sorry, I'm not familiar with all the bits gtk needs to function | 21:13 |
| zyga | chrisatlee: I'm sure gtk support will improve a lot soon but not tonight | 21:13 |
| === mwhudson_ is now known as mwhudson | ||
| tyhicks | zyga: even if we don't port safe_mounts(), we can rely on unshare(CLONE_NEWNS) to protect the system and other snaps from any symlink attacks via mount() | 21:16 |
| tyhicks | zyga: a potential problem is that the snap can trick snap-confine into bind mounting over portions of the os snap inside of the app's mount namespace | 21:17 |
| tyhicks | zyga: off the top of my head, I can't think of any attacks that it would allow but it does make me uneasy | 21:18 |
| zyga | ok, Ill port safe mount then | 21:20 |
| zyga | thanks :) | 21:20 |
| tyhicks | zyga: I think that's the safest option | 21:20 |
| sergiusens | chrisatlee hey, wrt gtk, you might be interested in the snappy-playpen | 21:21 |
| chrisatlee | sergiusens: yeah, I've been looking at some examples there | 21:22 |
| chrisatlee | using after: [gtkconf] | 21:22 |
| sergiusens | chrisatlee https://github.com/ubuntu/snappy-playpen | 21:22 |
| chrisatlee | it's a little insane that unspecified parts are pulled from the wiki! | 21:23 |
| chrisatlee | is there a way to delete non-current snaps? | 21:31 |
| sergiusens | chrisatlee then you will like 2.12 http://blog.sergiusens.org/posts/The-Snapcraft-Parts-Ecosystem/ | 21:32 |
| === bazhang_ is now known as bazhang | ||
| chrisatlee | any tips on debugging 'bad system call' when running under non-devmode? | 22:00 |
| zyga | chrisatlee: yes | 22:05 |
| zyga | chrisatlee: please look at syslog (journalctl -f -n 100) | 22:05 |
| zyga | chrisatlee: and look for the line that has syscall: 123 on it | 22:06 |
| zyga | chrisatlee: 123 is the number of the system call, you can resolve it with various tools | 22:06 |
| chrisatlee | 317 | 22:07 |
| zyga | chrisatlee: is this amd64 or another architecture? | 22:07 |
| chrisatlee | amd64 | 22:07 |
| chrisatlee | sig=31 arch=c000003e syscall=317 | 22:07 |
| zyga | that's seccomp itselr | 22:07 |
| zyga | itself | 22:07 |
| * zyga checks something | 22:07 | |
| zyga | chrisatlee: seccomp is allowed by default | 22:08 |
| zyga | chrisatlee: something is not okay, can you report a bug with the line that lists the syscall 317 | 22:08 |
| zyga | chrisatlee: please open the bug on launchpad.net/snappy | 22:09 |
| chrisatlee | yeah, if I add seccomp and unshare to the policy, it kind of works | 22:21 |
| chrisatlee | and now it's being denied access to /proc/$PID/task/.../stat | 22:22 |
| zyga | chrisatlee: it's better to report a bug on this, I wonder why seccomp was denied in the first place, seccomp is allowed for all programs | 22:37 |
| zyga | chrisatlee: (though remember that it only allows you to constrain the profile more, not less) | 22:37 |
| zyga | chrisatlee: what is the program you are trying to run? | 22:37 |
| chrisatlee | zyga: firefox | 22:50 |
| zyga | chrisatlee: firefox fro the package my have a nested apparmor/seccomp profile | 23:02 |
| zyga | chrisatlee: those won't work, you'd have to strip them out | 23:02 |
| zyga | chrisatlee: and also firefox probably uses seccomp internally but that should work | 23:02 |
| zyga | chrisatlee: though it'd be best to report this issue an let us investigate | 23:02 |
| chrisatlee | yeah, it uses it internally | 23:03 |
| zyga | chrisatlee: if you can, please include the snapcraft.yaml file so that we know what approach you've used | 23:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!