| mup | PR snapcraft#1043 closed: tests: fix the CLA launchpadlib install in travis <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1043> | 00:35 |
|---|---|---|
| mup | PR snapcraft#1043 opened: tests: fix the CLA launchpadlib install in travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1043> | 00:38 |
| snappy_irc | anybody know the localhost login details for ubuntu snap core ? | 01:10 |
| snappy_irc | I downloaded the ova from here http://cloud-images.ubuntu.com/snappy/devel/core/current/devel-core-amd64-cloud.ova?_ga=1.214375895.1790561723.1484162457 | 01:10 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| mup | PR snapcraft#1043 closed: tests: fix the CLA launchpadlib install in travis <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1043> | 03:23 |
| mup | PR snapcraft#1044 opened: tests: use python2 to check the CLA <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1044> | 03:29 |
| === chihchun_afk is now known as chihchun | ||
| === JanC is now known as Guest39941 | ||
| === JanC_ is now known as JanC | ||
| mup | Bug #1655834 opened: Support factory reset <Snappy:New> <https://launchpad.net/bugs/1655834> | 06:13 |
| mup | PR snapd#2544 closed: interfaces: implement login-control interface <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/2544> | 07:11 |
| zyga | o/ | 07:47 |
| zyga | hey mvo | 07:49 |
| mvo | hey zyga | 07:50 |
| mup | PR snapd#2554 closed: tests: add end-to-end store test for classic confinement <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2554> | 08:57 |
| mup | PR snapd#2605 closed: overlord,overlord/snapstate: have UpdateMany retire/enable auto-aliases even without new revision <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2605> | 08:57 |
| mup | PR snapd#2469 closed: interfaces: upower-observe: refactor to allow snaps to provide a slot <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2469> | 09:11 |
| mup | PR snapd#2616 opened: tests: test classic confinement `snap list` and `snap info` output <Created by mvo5> <https://github.com/snapcore/snapd/pull/2616> | 09:14 |
| mup | PR snapd#2617 opened: tests: switch more tests to MATCH <Created by zyga> <https://github.com/snapcore/snapd/pull/2617> | 09:26 |
| sergiusens | stokachu https://github.com/snapcore/snapcraft/blob/master/snaps_tests/__init__.py#L180 | 09:38 |
| stokachu | sergiusens, https://github.com/juju/juju/blob/staging/snapcraft.yaml | 09:46 |
| mup | PR snapcraft#1038 closed: misc: delete bzr ignore <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1038> | 09:50 |
| sergiusens | icey https://bugs.launchpad.net/bugs/1655832 | 10:03 |
| mup | Bug #1655832: App name in snapcraft.yaml must match case of .desktop file <Snapcraft:New> <https://launchpad.net/bugs/1655832> | 10:03 |
| icey | yeah sergiusens? | 10:05 |
| mup | PR snapd#2618 opened: tests: run all spread tests with SNAP_REEXEC={0,1} <Created by mvo5> <https://github.com/snapcore/snapd/pull/2618> | 10:47 |
| mup | PR snapd#2606 closed: overlord/snapstate: share code between Update and UpdateMany, so that it deals with auto-aliases correctly <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2606> | 11:30 |
| icey | sergiusens: I think I got the linker flags in | 11:48 |
| mup | PR snapcraft#928 closed: Add missing dependencies to install_requires <Created by javacruft> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/928> | 11:51 |
| zyga | jdstrand: FYI, snap-alter-ns won't be setuid root, it will just be started by snapd (like snap-discard-ns) | 12:02 |
| zyga | jdstrand: we can choose to confine it but I wanted to make sure you know this | 12:02 |
| mup | PR snapd#2567 closed: debian: skip snap-confine unit tests on nocheck <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2567> | 12:03 |
| mup | PR snapd#2619 opened: many: update 14.04 branch to top of master <Created by zyga> <https://github.com/snapcore/snapd/pull/2619> | 12:04 |
| mup | PR snapd#2616 closed: tests: test classic confinement `snap list` and `snap info` output <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2616> | 12:05 |
| mup | PR snapd#2620 opened: store: export userAgent. daemon: print store.UserAgent() on startup <Created by chipaca> <https://github.com/snapcore/snapd/pull/2620> | 12:06 |
| stokachu | how do i get into the shell of a snap again? | 12:25 |
| stokachu | snap run --shell conjure-up doesn't seem to do what i need | 12:25 |
| === ben_r_ is now known as ben_r | ||
| === hikiko_ is now known as hikiko | ||
| Chipaca | stokachu: `snap run --shell the-snap` should do what you need | 12:42 |
| Chipaca | stokachu: how is it not? | 12:42 |
| Chipaca | that is, what do you need, and what are you getting? | 12:42 |
| stokachu | so im building juju inside my snap but I think the problem is hte juju binary isn't getting copied into the snap | 12:43 |
| stokachu | still working that out | 12:43 |
| Chipaca | stokachu: that gives me more questions, but doesn't answer mine :-D | 12:43 |
| stokachu | yea sorry still trying to understand what im doing | 12:44 |
| stokachu | Chipaca: http://dpaste.com/361CKWW basically trying to expose the juju binary alongside conjure-up | 12:46 |
| morphis | mvo: do you know if there is a clear reason why every systemd service unit snapd generates wants the network-online.target? | 12:47 |
| Chipaca | stokachu: you did "snap run --shell conjure-up" | 12:47 |
| stokachu | Chipaca, yea | 12:47 |
| Chipaca | stokachu: what did that do? and what did you expect it to do? | 12:47 |
| stokachu | it brought me into a new shell and i was looking for the juju binary that wasn't there | 12:47 |
| Chipaca | stokachu: i'm missing somemething, i fear | 12:49 |
| stokachu | Chipaca, sorry, i built my conjure-up snap while pulling in the juju part from the wiki, in the end i want to be able to run both conjure-up and juju binaries from that single snap | 12:50 |
| Chipaca | stokachu: "snap run --shell conjure-up" is giving you a shell in the environment that apps in the conjure-up snap would see | 12:51 |
| Chipaca | stokachu: (modulo connections) | 12:51 |
| stokachu | Chipaca, ok, now im trying to figure out why that juju one isn't showing up in the file list | 12:51 |
| stokachu | Chipaca, using --classic | 12:51 |
| mvo | morphis: no clear reason | 12:51 |
| mvo | morphis: if that is a problem we can kill it | 12:51 |
| Chipaca | stokachu: when you say "in the file list", you mean in the snap? | 12:51 |
| stokachu | Chipaca, yea | 12:52 |
| stokachu | should it be conjure-up.juju as the command name? | 12:53 |
| Chipaca | yes | 12:53 |
| stokachu | how can i make it just juju? with an alias? | 12:53 |
| Chipaca | stokachu: yes | 12:53 |
| Chipaca | stokachu: but: is juju in conjure-up something users are expected to interact with? | 12:54 |
| stokachu | Chipaca, yea, juju needs to talk to the agent installed inside that snap | 12:54 |
| mup | PR snapd#2619 closed: many: update 14.04 branch to top of master <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2619> | 12:54 |
| morphis | mvo: not a urgent thing to fix but it conflicts with network-manager when I add a Alias=NetworkManager.Service in the generated unit file | 12:55 |
| morphis | as it then has a cycle of dependencies | 12:55 |
| === mcphail_ is now known as mcphail | ||
| stokachu | trying to get this juju binary include but hitting http://dpaste.com/2XNXGRW | 13:19 |
| stokachu | the part im pulling in is https://github.com/juju/juju/blob/juju-2.0.2/snapcraft.yaml | 13:20 |
| === beowulf_ is now known as beowulf | ||
| === hikiko_ is now known as hikiko|ln | ||
| morphis | zyga: any idea about https://paste.ubuntu.com/23786689/? I am using a 3.4 kernel here so could be something not well supported by that ancient kernel but would like to understand this a bit more | 13:35 |
| mup | PR snapd#2620 closed: store: export userAgent. daemon: print store.UserAgent() on startup <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2620> | 13:54 |
| zyga | morphis: looking | 14:04 |
| zyga | morphis: 3.4 | 14:04 |
| zyga | morphis: mount namespaces | 14:04 |
| zyga | morphis: do you see /proc/self/ns ? | 14:05 |
| zyga | morphis: if not then 3.4 is too old | 14:05 |
| zyga | I honestly don't expect 3.4 to work | 14:05 |
| morphis | https://paste.ubuntu.com/23786828/ | 14:11 |
| mup | PR snapd#2618 closed: tests: run some spread tests with SNAP_REEXEC={0,1} <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2618> | 14:12 |
| zyga | morphis: there's no mnt entry there | 14:12 |
| zyga | morphis: the error is confusing but 3.4 is too old | 14:12 |
| zyga | morphis: and there's no way to solve it easily without a major feature in snap-confine | 14:12 |
| zyga | (I discussed this a while ago but this is 2-3 weeks to do) | 14:13 |
| zyga | morphis: what is the HW if you can disclose this? | 14:13 |
| morphis | zyga: I see | 14:13 |
| zyga | morphis: if I end up writing this I'd like to know if I have it on my desk | 14:14 |
| === hikiko|ln is now known as hikiko | ||
| morphis | zyga: see PM | 14:20 |
| zyga | morphis: got it now | 14:28 |
| zyga | morphis: if we chat on rocket I get better notification | 14:28 |
| stokachu | zyga, snapstore supports delta downloads now right? | 14:53 |
| mup | PR snapd#2617 closed: tests: switch more tests to MATCH <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2617> | 14:59 |
| morphis | zyga: :-) | 15:00 |
| zyga | stokachu: yes but the client needs a special variable to enable that | 15:03 |
| stokachu | zyga, when will that get enabled by default? | 15:04 |
| zyga | stokachu: I don't know, that's a question to chipaca (not on IRC now) and nessita | 15:04 |
| stokachu | ok thanks | 15:04 |
| Chipaca | zyga, no, *you're* not on irc | 15:04 |
| zyga | oh | 15:04 |
| zyga | odd | 15:04 |
| zyga | tab tab gave me nothing, sorry about that | 15:04 |
| zyga | :) | 15:04 |
| Chipaca | we don't have delta downloads enabled by default | 15:05 |
| Chipaca | because of the xdelta3 dependency | 15:05 |
| stokachu | Chipaca, is that something that is in the works to be done soon? | 15:05 |
| Chipaca | stokachu, it's paperwork | 15:06 |
| Chipaca | but afaik it's moving forwards | 15:06 |
| Chipaca | so it'll get done in time | 15:06 |
| Chipaca | i mean: the code is there | 15:06 |
| stokachu | Chipaca, ah ok awesome | 15:06 |
| Chipaca | and you can even use it if you set the right env var | 15:06 |
| stokachu | cool is it documented anywhere? | 15:07 |
| Chipaca | dunno. SNAPD_USE_DELTAS_EXPERIMENTAL=1 in snapd's environ will do it | 15:07 |
| stokachu | cool thanks | 15:07 |
| Chipaca | and, you need xdelta3 | 15:08 |
| zyga | jdstrand: hey | 15:10 |
| zyga | jdstrand: did you read about the new BFP attachments to cgroups? | 15:12 |
| jdstrand | zyga: yes. I assume you are refering to the comment in the 'ip netns' PR. I just commented there | 15:19 |
| zyga | jdstrand: actually no, I read the article on LWN | 15:19 |
| zyga | jdstrand: I'll check the PR | 15:19 |
| jdstrand | zyga: the pr doesn't mention bpf, but it was talking about network mediation, so I thought you were going there | 15:21 |
| stokachu | hi could i get someone to take a look at https://myapps.developer.ubuntu.com/dev/click-apps/5479/rev/26/? | 15:24 |
| jdstrand | stokachu: I will | 15:25 |
| stokachu | jdstrand, ty! | 15:25 |
| mup | PR snapd#2621 opened: osutil.GetenvBool now takes an extra, optional, argument <Created by chipaca> <https://github.com/snapcore/snapd/pull/2621> | 15:28 |
| jdstrand | stokachu: done. you need to press the release button | 15:29 |
| stokachu | jdstrand, perfect ty, do i need to worry about getting additional reviews if i need to push a new snap? | 15:29 |
| jdstrand | stokachu: not now (I granted that). check your email | 15:30 |
| stokachu | jdstrand, ok great, thank you again | 15:30 |
| jdstrand | np | 15:30 |
| stokachu | jdstrand, sudo snap install conjure-up --edge --classic <- am i missing anything here? | 15:36 |
| stokachu | says snap isn't found | 15:36 |
| stokachu | oh isee | 15:37 |
| stokachu | release button at the bottom | 15:37 |
| stokachu | hmm not sure what im missing now | 15:38 |
| === chihchun is now known as chihchun_afk | ||
| stokachu | maybe there is a delay | 15:41 |
| stokachu | http://paste.ubuntu.com/23787291/ snap info does show it in the edge channel as well | 15:44 |
| pedronis | stokachu: some confusion but installing classic snaps from the store doesn't work in 2.20 or before (we are fixing it in 2.21) | 15:52 |
| stokachu | pedronis, ah | 15:53 |
| stokachu | pedronis, np i can just work with the blob itself for now | 15:53 |
| pedronis | stokachu: the workaround to try it is to use "snap download snap-name" "snap ack *.assert" "snap install *.snap" | 15:55 |
| stokachu | pedronis, ah perfect, that'll work | 15:55 |
| pedronis | sorry for the incovenience | 15:55 |
| stokachu | np i know it's very new | 15:56 |
| jdstrand | stokachu: there is an issue with snapd and the store when using --classic. I don't recall the details. I think sergiusens has a workaround | 15:59 |
| jdstrand | ah, I see you already got an answer to that :) | 16:00 |
| stokachu | jdstrand, :D | 16:00 |
| stokachu | i can still corner sergiusens tomorrow unless he's hiding from me | 16:00 |
| jdstrand | roadmr: hi! can you pull r824 of the tools? this is just updates to data/ for 2.21 interfaces and whitelisting some approved kernel and gadget snaps | 16:03 |
| roadmr | jdstrand: sure thing | 16:04 |
| jdstrand | roadmr: thanks! I *think* this will be it for a while (famous last words) | 16:04 |
| mup | PR snapd#2520 closed: many: fix abbreviated forms of disconnect <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2520> | 16:05 |
| mup | PR snapd#2622 opened: asserts: Improve error message when key is not valid at the given time <Created by mvo5> <https://github.com/snapcore/snapd/pull/2622> | 16:15 |
| Cust0sLim3n | hi | 16:28 |
| Cust0sLim3n | when will rhel/centos be supported | 16:28 |
| mup | PR snapd#2621 closed: osutil.GetenvBool now takes an extra, optional, argument <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2621> | 16:30 |
| ogra_ | Cust0sLim3n, perhaps SamYaple or zyga know if thats actually planned ... fedora is surely supported (with limitiations in the confinement) | 16:34 |
| elopio | hello Cust0sLim3n: https://github.com/snapcore/snapd/wiki/Distributions | 16:34 |
| Cust0sLim3n | thanks elopio | 16:36 |
| zyga | Cust0sLim3n: hey | 16:39 |
| zyga | Cust0sLim3n: CentOS needs some packaging work | 16:39 |
| zyga | Cust0sLim3n: Fedora has two blocking issues that we've struggled with | 16:39 |
| zyga | Cust0sLim3n: both are on the backlog but I expect ~1-2 weeks before I start working on that | 16:39 |
| Cust0sLim3n | zyga, is there some repo with stuff for CentOS / Fedora builds ? | 16:40 |
| zyga | Cust0sLim3n: please have a look at http://www.opera.com/pl/computer/neon | 16:40 |
| zyga | er | 16:40 |
| zyga | paste fail | 16:40 |
| zyga | http://github.com/snapcore/snapd/wiki/Distributions | 16:40 |
| zyga | Cust0sLim3n: there was COPR but it is no longer used as development moved to Fedora git | 16:40 |
| Cust0sLim3n | zyga, cool thanks | 16:41 |
| zyga | Cust0sLim3n: CentOS should be easier (no selinux on services by default) but it needs separate packaging permissions | 16:41 |
| zyga | Cust0sLim3n: if you are interested we could work together to revive copr and build a centos package there | 16:41 |
| zyga | Cust0sLim3n: I cannot commit 100% of my time to it this or next week but I will help you out | 16:41 |
| Cust0sLim3n | zyga, don't really have time - really need it for RHEL though - but I think in meantime I will just use software collections on rhel or something - still have to see | 16:42 |
| Cust0sLim3n | zyga, just thought it would be nice to use snappy instead of SCL | 16:42 |
| zyga | Cust0sLim3n: what software are you most interested in? | 16:43 |
| zyga | Cust0sLim3n: we'll get there, it's just a busy schedule all the time | 16:43 |
| Cust0sLim3n | zyga, its for commercial use with our C/C++ software on linux that I want it | 16:44 |
| Cust0sLim3n | zyga, but its not critical enough for us to dedicate allot of time to it - so it was mainly just if I somehow missed it being available it would have been nice - but otherwise we will just use SCL or package directly | 16:46 |
| zyga | Cust0sLim3n: how do software collections help you? | 16:46 |
| zyga | jdstrand: hey - new interfaces API: https://github.com/snapcore/snapd/pull/2613/files | 16:50 |
| mup | PR snapd#2613: interfaces: add new interface API <Created by zyga> <https://github.com/snapcore/snapd/pull/2613> | 16:50 |
| zyga | jdstrand: with initial review from gustavvo | 16:51 |
| zyga | jdstrand: I think it is likely to land soon | 16:51 |
| zyga | jdstrand: once it does expect a flag day where all the interfaces and backends are ported to provisional APIs like spec.AddSnippet() (that directly replaces returning a snippet) | 16:51 |
| jdstrand | I'll be looking at that in a little bit | 16:52 |
| zyga | jdstrand: and then dedicated changes to backends like mount, kmod, systemd that are well defined and have just a few interfaces | 16:52 |
| zyga | jdstrand: then we can discuss apparmor/seccomp | 16:52 |
| zyga | jdstrand: I think there's no rush on aa/sc but we can see what we'd like to do by porting one or two interfaces over to more semantic APIs | 16:52 |
| zyga | jdstrand: e.g. in seccomp we could do spec.Allow(seccomp.open) rather spec.AddSnippet("open") | 16:53 |
| zyga | jdstrand: in apparmor we could do (but in short cases IMHO) spec.Allow("/path/to/file", "r") or even spec.Allow("/path/to/file", apparmor.Read) | 16:53 |
| zyga | jdstrand: thanks! | 16:54 |
| Cust0sLim3n | zyga, makes it easier to work with multiple library and application versions and allows us to be less dependent on library versions shipping with OS - so if we want newer boost version for building with than is available on RHEL by default we can package it with SCL | 16:55 |
| jdstrand | zyga: keep in mind, I've not looked at this at all yet, but please, please, please keep in mind that the resulting security policy needs to be auditable. that means policy, structure and comments all need to be in place. I maintain my concerns that this will impede security audits since the review will have to do profile dumps to see what is happening | 16:56 |
| zyga | jdstrand: I keep this in mind and keep reminding everyone about it :-) | 16:56 |
| jdstrand | tyhicks: fyi ^ | 16:56 |
| mup | PR snapd#2623 opened: tests: add test ensuring manual pages are shipped <Created by zyga> <https://github.com/snapcore/snapd/pull/2623> | 17:00 |
| jdstrand | ogra_: hi! I noticed that the bbb kernel is a few versions behind the most recent USNs | 18:00 |
| jdstrand | ogra_: is your automated script not working right? | 18:01 |
| ogra_ | jdstrand, that one isnt automated ... i'll kick off a new build | 18:14 |
| jdstrand | ogra_: fyi, you can automate it if you want. I just added an exception for it in the review tools (though this upload will need a review, when the store syncs it won't any more) | 18:16 |
| ogra_ | ok | 18:16 |
| mup | PR snapd#2624 opened: Re-associate with pid-1 mount namespace if required <Created by zyga> <https://github.com/snapcore/snapd/pull/2624> | 18:41 |
| zyga | tyhicks: good news, I think I know what the kernel bug is about :) | 18:46 |
| zyga | (the one with oops on one thing I did a while ago) | 18:46 |
| zyga | well, fingers crossed | 18:46 |
| zyga | at the very least I can give you a way to reproduce easily | 18:46 |
| zyga | jdstrand, jjohansen: ^^ | 18:47 |
| zyga | (oops in apparmor) | 18:47 |
| zyga | on the up side it is *not* Friday yet | 18:47 |
| kgunn | ogra_: thanks for the pi image...one question, anyway we could change pi3 console config to not require ethernet cable? | 18:48 |
| kgunn | i set up wifi fine, but then it loops back and demands i set up via ethernet | 18:49 |
| ogra_ | kgunn, i think there is an old bug open for this ... | 18:49 |
| kgunn | ah | 18:49 |
| * kgunn thot pi2 didn't have wifi chip | 18:49 | |
| kgunn | and that was the reason | 18:49 |
| ogra_ | you can set it up initially with eth0, then reboot, ssh in and run "sudo console-conf" and disabe eth0 and switch to wlan0 ... that works fine for me | 18:50 |
| ogra_ | it is only the very first boot where it fails | 18:50 |
| davmor2 | ogra_: out of interest why are we use pi2 kernel on pi3 are there phyiscally no differences between then? | 18:50 |
| ogra_ | (but indeed you need network on the very first boot to set up the user) | 18:50 |
| zyga | ogra_: you can use the serial console | 18:51 |
| zyga | ogra_: on a pi :) | 18:51 |
| ogra_ | davmor2, the kernel is identical ... but th ebootloaders are not (namely there is a different u-boot.bin ) | 18:51 |
| jdstrand | jjohansen: this is not what we talked about yesterday, but zyga is seeing an oops with https://github.com/snapcore/snapd/pull/2624. I have a feeling many of your concerns about changing the mount namespace would apply to this pr | 18:51 |
| mup | PR snapd#2624: Re-associate with pid-1 mount namespace if required <Created by zyga> <https://github.com/snapcore/snapd/pull/2624> | 18:51 |
| ogra_ | zyga, for what ? | 18:51 |
| zyga | ogra_: to do the 1st boot dance | 18:51 |
| zyga | jdstrand: that branch is buggy but perhaps this is causing the oops | 18:51 |
| ogra_ | zyga, and that magically pulls the login data via serial ? | 18:51 |
| zyga | jdstrand: testing again with the fix | 18:51 |
| zyga | ogra_: oooooho | 18:51 |
| ogra_ | :D | 18:51 |
| zyga | ogra_: I should have gotten that beer | 18:52 |
| ogra_ | you need network to be able to finish console-conf once | 18:52 |
| ogra_ | hah | 18:52 |
| zyga | jdstrand: anything I should know about? | 18:52 |
| ogra_ | once it is finished, switching networks is easy | 18:52 |
| jdstrand | zyga: you should wait for jjohansen. he had concerns regarding changing namespaces and open fds and likely some other concerns | 18:53 |
| zyga | jdstrand: will he be around today? | 18:54 |
| jdstrand | zyga: this came up in the context of snap-alter-ns, but I think they would apply to this | 18:55 |
| zyga | jdstrand: hmm hmm, can you tell me how would snap-alter-ns be affected? we could presumably do all the open() calls after we re-associate | 18:55 |
| zyga | (just worried if I should be worried) | 18:55 |
| jdstrand | zyga: he should be. he has been sick though. not sure when he'll be online | 18:55 |
| jdstrand | zyga: need to wait for jjohansen. we were going to chat today. may as well make it all 3 of us | 18:56 |
| jdstrand | (or maybe tomorrow) | 18:56 |
| zyga | jjohansen: I'm sorry to hear that, I hope you get better | 18:56 |
| zyga | jdstrand: if he's around can you please PM me on telegram (I get notifications on my phone this way) | 18:57 |
| zyga | I'd like to listen to understnad this problem better | 18:57 |
| jdstrand | zyga: you can listen to irc then? | 18:57 |
| zyga | jdstrand: if the converstation is on IRC then that's much easier :) | 18:59 |
| jdstrand | zyga: it will be, yes | 19:00 |
| zyga | jdstrand: somewhat offtopic, I think there's a separate bug, kernel doesn't let me bind() the mount namespace FD if I don't run as root despite having all the capabilities; I will need to investigate that in ~10 days. Do you know if this is by design (by any chance)? | 19:02 |
| jdstrand | zyga: I don't, sorry | 19:04 |
| * zyga will dig through the kernel then | 19:04 | |
| alvarolb | hi there! How I can submit a snap package both for armhf and amd64? I have both snaps already built. | 19:05 |
| zyga | alvarolb: just send them to the store | 19:05 |
| zyga | alvarolb: you can use snapcraft for that | 19:05 |
| zyga | alvarolb: or use the web UI | 19:05 |
| zyga | alvarolb: both snaps need to have the same snap name / snap id | 19:05 |
| zyga | alvarolb: and (hopefully) different architecture entries | 19:05 |
| alvarolb | yes, but if I upload the amd64 | 19:06 |
| kyrofa | alvarolb, they will both be assigned different revisions and the store will know what arch they are. And snapd won't let a snap for the wrong arch be installed | 19:06 |
| alvarolb | then it replaces the armhf | 19:06 |
| zyga | alvarolb: it doesn't really replace them | 19:06 |
| zyga | alvarolb: just try it, you will have to publish each one | 19:06 |
| zyga | alvarolb: then you should be able to install them :) | 19:06 |
| alvarolb | Ok, so I upload both versions to the same snap package, and it should work | 19:07 |
| kgunn | ogra_: re eth, ack...except i don't have eth cable access here at my communal office space :-P | 19:07 |
| alvarolb | it does not show that the snap is available for both platforms | 19:07 |
| kyrofa | alvarolb, then run `snapcraft status <snapname>` and you'll see where each arch has its own channel map | 19:07 |
| ogra_ | kgunn, ah, damned | 19:08 |
| ogra_ | kgunn, well, we dont have a solution beyond this yet | 19:09 |
| ogra_ | you could try a wifi dongle, perhaps that works better | 19:10 |
| alvarolb | ok, thanks for the support! | 19:10 |
| mup | PR snapd#2433 closed: tests: run all snap-confine tests in c-unit-tests task <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2433> | 19:15 |
| mhall119 | jdstrand: can you take a look at this error for me? http://paste.ubuntu.com/23788349/ | 19:36 |
| mhall119 | I suspect that it's not really a problem with the limits, but rather the snap's inability to check what the limits are, due to confinement | 19:36 |
| zyga | mhall119: Jan 12 14:31:59 mhall-thinkpad snap[5671]: /snap/couchbase-server-community/x1/couchbase-server-snap: line 166: exec: erl: not found | 19:38 |
| zyga | mhall119: limits seem to be a separate issue | 19:38 |
| zyga | mhall119: look at dmesg | DENIED please | 19:39 |
| zyga | er | 19:39 |
| zyga | dmesg | grep DENIED | 19:39 |
| mhall119 | zyga: nothing from couchbase there, I have another issue with it not finding the 'erl' binary that I need to fix | 19:40 |
| stokachu | so in a classic snap how would i copy a file to my HOME dir? | 19:49 |
| zyga | mhall119: then I'd say it dies on that problem now | 19:49 |
| stokachu | not the home dir of the snap | 19:49 |
| zyga | stokachu: classic snap or in the classic confinement of some snap/ | 19:50 |
| stokachu | zyga, in the classic confinement | 19:50 |
| zyga | stokachu: snaps that have confinement: classic don't get HOME redirection | 19:50 |
| zyga | stokachu: HOME is real :) | 19:50 |
| zyga | stokachu: try it, | 19:51 |
| stokachu | hmm so if i do a cp file ~/test from the snap it doesn't show up in my HOME dir | 19:51 |
| zyga | stokachu: https://github.com/snapcore/snapd/wiki/Environment-Variables#home | 19:51 |
| zyga | stokachu: can you use "snap run --shell $SNAP_NAME.appname" and go to $HOME | 19:51 |
| zyga | stokachu: or just echo $HOME | 19:52 |
| zyga | stokachu: if that's a bug I can (still) fix it | 19:52 |
| stokachu | zyga, hmm ok $HOME shows my user (ubuntu) /home/ubuntu when i do a snap run --shell conjure-up | 19:53 |
| stokachu | need to check out my code then, because things like os.expanduser in python should work as normal correct? | 19:53 |
| stokachu | yea must be something in my code | 19:54 |
| * stokachu back to drawing board | 19:54 | |
| AlbertA | ogra_: this may be a different bug (wifi), I ran console-conf after first boot like you mentioned but | 19:58 |
| AlbertA | wlan0 option dissapears | 19:58 |
| zyga | stokachu: I hope so, we don't change anything else | 20:00 |
| AlbertA | ogra_: I guess a reboot fixed that :) | 20:00 |
| stokachu | zyga, hah | 20:00 |
| zyga | jdstrand: hey, so I made some progress but got stuck; I don't see any apparmor denials (the process is in devmode), I don't see anything in the kernel log but when I open /proc/1/ns/mnt I get EACCES | 20:05 |
| zyga | jdstrand: I did an experiment where I just nsenter around and this worked OK | 20:05 |
| zyga | jdstrand: I suspect apparmor is causing this | 20:05 |
| zyga | jdstrand: can you please have a look at https://github.com/snapcore/snapd/pull/2624/files#diff-5f1642833244a655796f5f4230f68fdbR207 | 20:06 |
| mup | PR snapd#2624: Re-associate with pid-1 mount namespace if required <Created by zyga> <https://github.com/snapcore/snapd/pull/2624> | 20:06 |
| zyga | jdstrand: and tell me if I need to adjust the apparmor profile in some special way (in the same pull request) | 20:06 |
| mup | PR snapcraft#1045 opened: Handle parser errors better <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1045> | 20:06 |
| zyga | jdstrand: note, I *don't* get a DENIED anywhere :-( | 20:06 |
| zyga | jdstrand: (thinking about it now I want to point out that while the process running snap-confine is in devmode, snap-confine itself is obviously confined) | 20:06 |
| zyga | jdstrand: perhaps my change is not applied to the snap-confine I'm runnning from the (repackaged) core snap? | 20:07 |
| zyga | jdstrand: still thinking aloud, looking at /sys/kernel/security/apparmor/profiles I see | 20:08 |
| zyga | http://paste.ubuntu.com/23788499/ | 20:08 |
| zyga | jdstrand: should snap confine reset the policy (maybe this should be done in the base apparmor template, running snap confine doesn't inerhit the profile but replaces it with the profile for snap-confine) | 20:10 |
| zyga | jdstrand: insight appreciated, I'll check back later | 20:10 |
| zyga | jdstrand: I've added some more facts here: https://github.com/snapcore/snapd/pull/2624#issuecomment-272270130 | 20:19 |
| mup | PR snapd#2624: Re-associate with pid-1 mount namespace if required <Created by zyga> <https://github.com/snapcore/snapd/pull/2624> | 20:19 |
| * zyga EODs | 20:19 | |
| ogra_ | AlbertA, yeah, wla0 is there and you can even attempt to configure it but it will always fail in the end | 20:22 |
| ogra_ | second attempt is stable | 20:22 |
| roadmr | jdstrand: you got lucky and we had a clear store deployment pipeline; tools r824 is now in production | 20:29 |
| jdstrand | \o/ | 20:30 |
| jdstrand | roadmr: thanks :) | 20:30 |
| lazyPower | o/ heyo, trying to use snapcraft from MASTER. My tests pass save for some subclass issues (about 7 failures that seem unrelated) - however when attempting to use snapcraft, i get the following message: Issues while validating snapcraft.yaml: snapcraft validation file is missing from installation path | 20:41 |
| kyrofa | lazyPower, how are you running snapcraft? | 20:45 |
| lazyPower | kyrofa - i followed the hacking guide to install it (isolated in a lxd container) | 20:49 |
| lazyPower | kyrofa - after the predep steps, python setup.py install && cd $my-snaps-path && snapcraft | 20:50 |
| lazyPower | s/python/python3/ | 20:50 |
| kyrofa | lazyPower, the hacking guide only discusses dependencies, not snapcraft itself | 20:50 |
| kyrofa | lazyPower, when it comes time to run it, simply run bin/snapcraft (or add it to your PATH) | 20:51 |
| jdstrand | mhall119: your system seems to have 'nofile' set somewhere. you can see your limits by typing 'ulimit'. I did just now on classic, in hello-world on classic and hello-world on all snaps and they all say 'unlimited'. see man limits.conf and /etc/security/limits.conf | 21:21 |
| jdstrand | mhall119: are you seeing any security denials? | 21:21 |
| jdstrand | zyga: re https://github.com/snapcore/snapd/pull/2624/file if there is no denial, it shouldn't be apparmor. the kernel might be telling you EACCES for another reason. that said, I think we should ask jjohansen about it | 21:23 |
| mup | PR snapd#2624: Re-associate with pid-1 mount namespace if required <Created by zyga> <https://github.com/snapcore/snapd/pull/2624> | 21:23 |
| jjohansen | looking | 21:24 |
| jdstrand | zyga: when you use nsenter, are you doing it from within snap-confine at the point that it is getting the EACCES? ie, nsenter from global namespace to pid 1 namespace is one thing, some snap app running anohter snap app that triggers snap-confine to have it go to pid 1 is another thing | 21:26 |
| jdstrand | jjohansen: ^ that is the summary of the issue | 21:27 |
| jjohansen | right | 21:27 |
| jdstrand | jjohansen: let's wait for zyga to respond on that. do you have time to discuss snap-alter-ns? (what we discussed yesterday) | 21:30 |
| jjohansen | we discusssed it? | 21:30 |
| jdstrand | well | 21:30 |
| jdstrand | we referenced it? | 21:31 |
| jdstrand | the thing from yesterday :) | 21:31 |
| jjohansen | right | 21:31 |
| jdstrand | (which isn't the same thing as the above pr) | 21:31 |
| jdstrand | jjohansen: you have time now? | 21:31 |
| jjohansen | sure, I guess | 21:32 |
| jdstrand | jjohansen: ok. so let me give you the problem and a simple description of what the propsed solution is, then the url for the din depth description of the fix | 21:33 |
| jdstrand | jjohansen: today snaps can ship multiple commands. those commands may be daemons or manually started. all commands within a snap share the same mount namespace, so the all see the same /tmp and things that snapd might mount into the namespace | 21:34 |
| jdstrand | jjohansen: this is done by when a snap command is first started, a nsfs magic file is checked. it is isn't magic, the full mount namespace is setup, then the magic file is saved. the next command that runs see the magic file and snap-confine enters that mount namespace instead of generating it anew | 21:36 |
| jdstrand | jjohansen: on top of that, there is an interface called 'content'. this allows a providing snap to 'export' something in its area so that another snap may 'import' it. this is done via a file that maps the export dir to the import dir that snap-confine reads and it will perform a mount of the exported dir into the calling snaps mount namespace | 21:38 |
| jdstrand | jjohansen: iirc, things work fine if the interfaces are connected (ie, snap-confine is supposed to do this mount operation) and the mount namespace is not setup (eg, after a reboot). there have been some issues with if the mount namespace is setup already iirc and adding it after the mount namespace is already setup. (eg, start the command, then connect the interface, etc) | 21:41 |
| jdstrand | jjohansen: so zyga came up the the idea of 'live modification of mount namesapces' | 21:41 |
| === smoser` is now known as smoser | ||
| jdstrand | jjohansen: in essence, that is meant to robustly perform the mount of the imported directory on a namespace that is already setup, and remove mounts that have been disconnected | 21:42 |
| jdstrand | jjohansen: I mentioned that removing mounts will cause problems with daemons most likely-- I think he will counter that they'll lazy umount. | 21:43 |
| jdstrand | jjohansen: the live modification will be done by 'snap-alter-ns', a command that snapd will call when a 'snap connecnt' or 'snap disconnect' is performed. it is meant to mount missing connected imports and unmount ones that are no longer connected | 21:44 |
| jdstrand | jjohansen: here is the larger proposal: https://github.com/snapcore/snapd/wiki/Live-Modification-Of-Mount-Namespaces | 21:44 |
| jdstrand | jjohansen: <I'm done> | 21:45 |
| jdstrand | jjohansen: well, I have one final thought. revocation aside, I thought that simply adding mounts would not be problematic since that isn't really any different than say plugging in a usb key and having it show up. that said, there are many layers of mounts here and that may be a naive way of looking at it | 21:47 |
| jjohansen | okay, removing mounts can be problematic for any open fd, but it is probably something that isn't a blocker | 21:48 |
| zyga | re | 21:48 |
| zyga | hey | 21:48 |
| * zyga watched 2nd episode of 4th season of Sherlock | 21:48 | |
| zyga | jdstrand: replied on your comment | 21:48 |
| zyga | jdstrand: according to my experiment this only happens when apparmor is in the loop, I could have made a mistake, I was tired already | 21:49 |
| zyga | 22:26 < jdstrand> zyga: when you use nsenter, are you doing it from within snap-confine at the point that it is getting the EACCES? ie, nsenter from global namespace to pid 1 | 21:49 |
| zyga | namespace is one thing, some snap app running anohter snap app that triggers snap-confine to have it go to pid 1 is another thing | 21:49 |
| jjohansen | additions at first glance look safer, but have the potential to create aliases and rewrite subtree. If tightly controlled it should be okay, if not it is an attack vector | 21:49 |
| zyga | jdstrand: to reply to this: when I use nsenter I was doing it from the mount namespace created by snap-confine | 21:50 |
| zyga | I'm happy to discuss anything | 21:50 |
| jdstrand | zyga: let's pause on 2624 for a moment and get through snap-alter-ns | 21:51 |
| zyga | ok | 21:51 |
| jjohansen | zyga: can you turn on apparmor debug messages | 21:51 |
| jjohansen | echo 1 > /sys/modules/apparmor/parameters/debug | 21:51 |
| jjohansen | and see if that turns anything up, also turn off printk rate limiting to make sure printk isn't dropping something | 21:51 |
| jjohansen | echo 0 > /proc/sys/kernel/printk_ratelimit | 21:51 |
| zyga | jjohansen: ack, I'll do that | 21:52 |
| jdstrand | jjohansen: wrt aliases and rewrite subtree, how would one trigger that? right now, the snap declares a dir and that is it. is it a malformed dir? a symlink? something in the dir that could trigger it? | 21:52 |
| jdstrand | oh I forgot rate limiting | 21:52 |
| jjohansen | apparmor shouldn't be denying something without logging it, hmmm unless explicitly told not to log it, better turn off quieting as well | 21:52 |
| jjohansen | echo -n noquiet > /sys/module/apparmor/parameters/audit | 21:52 |
| jdstrand | jjohansen: we don't actually explicitly much in the snappy policy (I think there are two rules otoh) | 21:53 |
| jdstrand | but noquiet never hurts | 21:53 |
| jjohansen | just trying to make sure all potential reasons not to log are out of the way | 21:55 |
| zyga | ok, test in progress | 21:55 |
| zyga | let's talk about snap-alter-ns | 21:55 |
| jdstrand | (fyi, you need sys_admin for entering the namespace and snap-confine has that) | 21:56 |
| zyga | correct | 21:56 |
| jdstrand | jjohansen: did you see my last question? | 21:56 |
| * zyga finishes reading backlog | 21:58 | |
| jjohansen | jdstrand: you mount over an existing dir/tree location that isn't a leaf | 21:58 |
| jjohansen | it just has to be controlled is all | 21:59 |
| jdstrand | jjohansen: like, twp exported dirs mounted onto the same import dir? | 21:59 |
| zyga | I'm fine with limiting this so that we can guarantee no "funny" layouts are possible | 21:59 |
| jdstrand | jjohansen: it is rather tightly controlled right now. I want to make sure we make sure we get all the bits | 21:59 |
| zyga | you should also be aware with one more thing we're trying to introduce that may complicate this | 21:59 |
| zyga | the 'overmount' interface, that within the snap's mount namespace, allows it to almost freely do bind mounts from $SNAP to various places across the fileystem; the use case is shoving stuff into /usr/share so that pre-compiled binaries feel more at home | 22:00 |
| jdstrand | zyga: can you add to your list a check to make sure that you can't mount on an already mounted location? ie, no layering at all | 22:00 |
| zyga | jdstrand: so essentially the target directory cannot itself be a mount point | 22:01 |
| jdstrand | zyga: that is how I took jjohansen's comment. let's get his feeback | 22:01 |
| zyga | jdstrand: will this restriction cause any issues to users? | 22:01 |
| zyga | ok | 22:01 |
| jdstrand | zyga: I think blocking that is a good thing despite this. it would be weird to have two content exports mounted over each other. which would win? poor user experience | 22:02 |
| zyga | agreed | 22:03 |
| zyga | are we considering *any* mount points or just those that interfaces created? | 22:03 |
| jdstrand | jjohansen: ^ | 22:04 |
| zyga | /bin/bash: line 44: /sys/modules/apparmor/parameters/debug: No such file or directory | 22:06 |
| jjohansen | jdstrand: well sure that is one, doesn't really matter any non-leaf mount can result in weirdness, as you have a shadowing affect | 22:06 |
| zyga | hmm | 22:06 |
| jjohansen | ie. alias | 22:06 |
| zyga | ah, module vs modules | 22:06 |
| jdstrand | with the content interface I think this is ok | 22:07 |
| zyga | jjohansen: can you give me an example of a mount that would be problematic | 22:08 |
| jjohansen | whether its good or bad depends on what you are trying to achieve, but it adds to the complexity of what needs to be analyzed and opens the potential for attacks that you don't see. I think you probably okay, the mounts are being done by snapd not the application | 22:08 |
| zyga | jjohansen: I'd like to understand what to avoid better | 22:08 |
| jdstrand | we are mounting into a dir that shouldn't have any mounts (well, could be on a dir in a squashfs) | 22:08 |
| jdstrand | jjohansen: gotcha | 22:09 |
| jjohansen | zyga: that is a good question, and the answer is it depends | 22:09 |
| jdstrand | zyga: I think we are ok cause the content interface is mounting into a very specific place-- either in SNAP, SNAP_COMMON or SNAP_DATA. there shouldn't be anything else in there if we employ the outlined restriction | 22:10 |
| jjohansen | some of it, I just don't know. Aliasing attacks via links etc have been pulled off in the past. I think we largely don't have that problem with snappy | 22:10 |
| jjohansen | the other thing to worry about the interaction between the different mechanisms providing your policy, which is a combination of namespaces, dac, apparmor, and seccomp | 22:11 |
| jdstrand | (snaps can't mount (excepting a few super restricted interfaces that are only allowed to trusted apps)) | 22:11 |
| zyga | jdstrand: if the overmount interface lands that comfort will go away, e.g. I can connect overmount and then content and then disconnect overmount, given the right (or evil) interfaces that could do some things we weren't expecting | 22:11 |
| jdstrand | zyga: I have quite a few concerns with the overmount interface | 22:12 |
| jjohansen | they each have their own set of expectations, I think the interaction between apparmor path mediation and mount namespacs is the most problematic | 22:12 |
| jjohansen | again its just a matter of making sure your policy is right for the changes | 22:12 |
| jdstrand | based on what we said here, I think we are good. we can deal with overmount if/when it comes up for review | 22:13 |
| zyga | can you wait 5 more minutes, I will have that debug data | 22:14 |
| jdstrand | it is too difficult to think about the policy ramifications of what it could someday do ("it can do anything!" I can't evaluate the impact on policy for 'anything' :) | 22:14 |
| zyga | I was looking at loaded profiles and I saw that there were "//null" in the profile names, that made me worries somewhat, are those expected? I don't quite understand how profiles stack or what to make of the profile name | 22:14 |
| zyga | (after the reassociation test failure) | 22:15 |
| jdstrand | jjohansen: wrt revocation with snap-alter-ns. today we don't revoke so there isn't an issue. with snap-alter-ns, I suspect that zyga will use a lazy umount. do you see problems there? | 22:15 |
| jdstrand | zyga: //null is normal when you are in complain mode | 22:15 |
| jjohansen | zyga: //null should only ever showup for profiles that are auto-generated during complain mode | 22:16 |
| jjohansen | they will either be //null-#### where #### is unique, or //null-executable name | 22:17 |
| zyga | dmesg http://paste.ubuntu.com/23789099/ | 22:17 |
| zyga | kern.log http://paste.ubuntu.com/23789105/ | 22:17 |
| jdstrand | we got back to talking about two things at once | 22:17 |
| zyga | this is the same test with the extra debugging | 22:18 |
| jdstrand | we can finish snap-alter-ns if the revocation question is answered | 22:18 |
| zyga | ah, sorry, I'm always too impacient | 22:18 |
| zyga | [ 498.595560] apparmor: clearing unsafe personality bits. /usr/lib/snapd/snap-confine label=snap.test-snapd-tools.cmd//null-/usr/bin/snap//null-/usr/lib/snapd/snap-confine | 22:19 |
| jjohansen | zyga: so I don't see apparmor directly causing the failure but, it is possible that clearing the unsafe personality bits could lead to an EACCES | 22:19 |
| zyga | actually | 22:19 |
| zyga | [ 498.616822] audit: type=1400 audit(1484259403.009:67): apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="snap.test-snapd-tools.cmd//null-/usr/bin/snap//null-/usr/lib/snapd/snap-confine" name="" pid=25299 comm="snap-confine" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 | 22:19 |
| zyga | isn't this exactly what I saw? | 22:19 |
| zyga | I got errno 13 | 22:20 |
| zyga | jjohansen: I was reading the log in order, this is the last message | 22:20 |
| jdstrand | can we put that on hold? I have a question regarding it that will require discussion | 22:20 |
| zyga | sure | 22:20 |
| jdstrand | there is but one question remainging... | 22:20 |
| jdstrand | jjohansen: wrt revocation with snap-alter-ns. today we don't revoke so there isn't an issue. with snap-alter-ns, I suspect that zyga will use a lazy umount. do you see problems there? | 22:20 |
| jjohansen | oh, hrmmm, if there is an ALLOWED it should be toggling the error to 0, the logging does report the initial error | 22:21 |
| jjohansen | I am not ruling out that there is a bug around complain mode and disconnected paths | 22:21 |
| jjohansen | jdstrand: sure, lazy unmount tringgers disconnected paths | 22:22 |
| jdstrand | ah | 22:22 |
| jdstrand | zyga: so I'm not sure we can do live revocation well with snap-alter-ns | 22:22 |
| zyga | jdstrand: hmm hmm | 22:23 |
| jdstrand | zyga: daemons or anything already running in the mount namespace are going to be unhappy | 22:23 |
| jjohansen | jdstrand: with that said, if the fd label is cached it should be fine | 22:23 |
| zyga | jdstrand: we could ignore that and just carry on (to some extent) | 22:23 |
| zyga | jdstrand: we could fail the operation and say "gee, cannot disconnect this thing now" (bad UX perhaps, need to re-do some mounts) | 22:23 |
| jdstrand | zyga: I think snap-alter-ns will make connect more robust | 22:23 |
| jjohansen | the issue would rear its head if new lookups (openat, ...) are done based off of it, or policy is replaced | 22:23 |
| jdstrand | policy gets replaced on connect/disconnect | 22:24 |
| jjohansen | jdstrand: well, then we are going to have to spend some time looking at it | 22:24 |
| jdstrand | zyga: I like the idea of trying to umount non-lazy. if it fails, it just doesn't get unmounted. it gets removed from the saved file. eventually it is gone | 22:24 |
| jjohansen | jdstrand: it will depend on several things, and stacking opens up some avenues that might make it not a problem | 22:25 |
| jdstrand | zyga: I think more than that will require tyhicks or ratliff in on the conversation so that scope and priority can be discussed | 22:25 |
| jdstrand | jjohansen: ack | 22:25 |
| zyga | jdstrand: we could also consider saying "this doesn't work" and having snapd shutdown all the stuff that runs there | 22:26 |
| zyga | jdstrand: so in the nice case it just works | 22:26 |
| jdstrand | I'm ready to move past revocation if you guys are | 22:26 |
| zyga | jdstrand: in the non-nice case it just reliably gets closed | 22:26 |
| zyga | I think we need to try it and meet again to discuss what kind of warts remain | 22:26 |
| zyga | jjohansen: what do you think? | 22:26 |
| jdstrand | zyga: well-- restarting a daemon wouldn't be too bad, but there is no way to restart a non-daemon command that is running | 22:26 |
| zyga | jdstrand: ah, correct | 22:26 |
| zyga | jdstrand: I didn't consider this | 22:27 |
| zyga | jdstrand: we could use cgroups to do this though | 22:27 |
| zyga | freeze and kill | 22:27 |
| jdstrand | zyga: that said, snap-alter-ns and its way of managing the saved file sounds fine and will make the connect more robust. we can ponder disconnect and defer | 22:27 |
| jjohansen | zyga: yeah, meeting again sounds good | 22:27 |
| jdstrand | eh | 22:27 |
| zyga | jdstrand: sounds good, I think most people will struggle with connect more :) | 22:27 |
| jdstrand | I'd be pretty miffed if I lost all my state | 22:27 |
| jdstrand | zyga: I do too | 22:28 |
| zyga | jdstrand: connect is interactive | 22:28 |
| zyga | jdstrand: we could do something smart like "are you *really* sure you want this?" | 22:28 |
| jjohansen | zyga: so if you add attach_disconnected to your profile, and test again that should tell us whether the failure is a bug in how apparmor is handling disconnected paths wrt complain mode | 22:28 |
| zyga | jjohansen: this is attach_disconnected already I think | 22:29 |
| zyga | jjohansen: there are only two profiles at play: (and a hat): snap-confine, base policy all snaps get and the hat in snap-confine | 22:29 |
| * zyga checks | 22:29 | |
| zyga | I have a debug shell so I can experiment if you have ideas | 22:29 |
| jjohansen | zyga: nope, you won't get info="Failed name lookup - disconnected path" | 22:29 |
| jjohansen | well not unless that is a bug too ... | 22:30 |
| jdstrand | zyga: ok, so now my question-- why is snap-confine calling snap to call snap-confine from within the profile? I think the snap command needs to be the thing that sets everything straight. ie, snap can talk to snapd which can notice if the comamnd is running under confinement, then check if the confinement allows calling the command, then fork/exec to call snap itself | 22:30 |
| jdstrand | you are focusing on devmode, but I don't know how this is expected to work in strict mode policy-wise | 22:30 |
| zyga | jjohansen: snap-confine has that, looking at the generated profile now | 22:31 |
| jdstrand | so snapd is a trusted helper | 22:31 |
| zyga | jdstrand: this is a feature for CE, in devmode only they need to be able to run a snap command from another snap command, before mount namespace tricks it use to work so they treat it as a regression | 22:31 |
| jdstrand | I know that has problems with fds, etc, etc, but so does this method | 22:32 |
| zyga | jdstrand: this is only expected to work in devmode (for them) | 22:32 |
| zyga | jjohansen: I confirmed that all profiles are attach_disconnected | 22:32 |
| zyga | I can pastebin them if you like | 22:33 |
| zyga | qemu:ubuntu-16.04-64 .../tests/regression/lp-1644439# cat /sys/kernel/security/apparmor/profiles |pastebinit | 22:33 |
| jjohansen | zyga: does /sys/kernel/security/apparmor/policy/raw_data/ exist? | 22:33 |
| zyga | http://paste.ubuntu.com/23789168/ | 22:33 |
| zyga | checking | 22:33 |
| zyga | yes | 22:34 |
| jdstrand | looking at line 91 and the lines after, I feel like maybe snap-confine is trying to transition to the hat but can't find it | 22:34 |
| zyga | but empty | 22:34 |
| zyga | jdstrand: note that this is _before_ the hat | 22:34 |
| jjohansen | gah, never mind. I've got it. The null child profile is not picking up the flags of the parent, so it is not attach_disconnected | 22:34 |
| zyga | jdstrand: the reassociation is done before we even attempt to fork | 22:34 |
| jjohansen | zyga: can you open a bug | 22:35 |
| zyga | jjohansen: sure, just tell me where | 22:35 |
| jdstrand | this is a funky denial: apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="snap.test-snapd-tools.cmd//null-/usr/bin/snap//null-/usr/lib/snapd/snap-confine" name="" pid=25299 comm="snap-confine" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 | 22:35 |
| jdstrand | name=""? | 22:35 |
| zyga | jjohansen: I can boot other kernels, test anything, this is easy to reproduce | 22:35 |
| zyga | well, it doesn't know what the name is | 22:35 |
| jjohansen | zyga: drop your failure and log in the bug, open it again linux or apparmor it doesn't really matter | 22:35 |
| jdstrand | zyga: do you have a reproducer for jjohansen that doesn't involve spread? | 22:35 |
| jjohansen | zyga: name="" means that its going to attach to / | 22:36 |
| zyga | jdstrand: spread just runs those few shell commands, all you need to do is to build s-c from that branch and then you can do it easily | 22:36 |
| zyga | jjohansen: I'll file one shortly | 22:36 |
| jjohansen | disconnected paths don't have a leading / and currently the only connection point is / | 22:37 |
| zyga | jdstrand: and this is in qemu, | 22:37 |
| zyga | (pretty easy to set up) | 22:37 |
| jdstrand | zyga: can you make sure that the bug has very clear instructions for reproducing and building s-c? | 22:37 |
| zyga | jdstrand: sure | 22:37 |
| zyga | jdstrand: I'll try to simplify it if I can | 22:37 |
| zyga | but this is pretty robust, just clone that branch and run spread with a given argument | 22:37 |
| jdstrand | zyga: jjohansen is trying very hard to hit a merge window for upstreaming apparmor and he doesn't hack on snap-confine or snapd :) | 22:37 |
| zyga | and you have shell in the qemu box :) | 22:37 |
| zyga | point taken | 22:38 |
| zyga | btw, how is that progressing? | 22:38 |
| jjohansen | zyga: I don't need the reproducer, just the bug. I should have a kernel for you in a few hours | 22:38 |
| jdstrand | zyga: yeah, don't expect that to be fast for him :) he doesn't have any of that setup. a shell script or .c file demontrating the problem is way better than bootstrapping the snapd dev environment | 22:38 |
| zyga | jjohansen: looking forward to that | 22:38 |
| jdstrand | sounds like jjohansen has it under control and I've said my bits, so I'm out | 22:39 |
| zyga | I'll report the bug now | 22:39 |
| zyga | thanks guys, it was good to talk to you again :) | 22:39 |
| jdstrand | np | 22:40 |
| jdstrand | jjohansen: thanks for all your time! :) | 22:40 |
| wililupy | Question: I have a user that built a custom kernel and they are trying to install it with the snap install command but it fails saying it is not signed. They used the --dangerous and equivilent options to no avail. Is there any other command line flags to use when trying to do this? | 22:47 |
| zyga | wililupy: you need to build an image with this but I don't believe this option is supported in ubuntu image yet | 22:47 |
| kyrofa | zyga, is there no way to use a custom kernel, then? | 22:49 |
| wililupy | zyga: Thats what I thought. I told them that and sent them instructions on building a custom image but I also told them I would get a difinitive answer on this as well. Thanks. | 22:49 |
| zyga | jmm | 22:49 |
| zyga | maybe I'm confusing building an image with devmode snaps and building with a unsigned kernel | 22:49 |
| * zyga doen't know | 22:49 | |
| kyrofa | barry, help? | 22:50 |
| wililupy | kyrofa: when I build custom images, I use custom kernels and it works. I never tried snap install kernel.snap but they did and told me what happened. | 22:51 |
| kyrofa | wililupy, ah, so ubuntu image _does_ support this? | 22:51 |
| kyrofa | wililupy, was the install attempted on classic ubuntu, or in ubuntu core? | 22:52 |
| wililupy | kyrofa, yes. in the assertion I use my custom kernel's name value and then use --extra-snaps and the kernel.snap and it builds and runs no problems. | 22:52 |
| wililupy | kyrofa: ubuntu-core. | 22:53 |
| kyrofa | wililupy, okay good, glad to know that works. barry unping | 22:53 |
| kyrofa | wililupy, I kinda feel like you should be able to install --dangerous on core though... otherwise testing a custom kernel is rough, no? | 22:53 |
| kyrofa | I wonder about the reason behind that | 22:54 |
| wililupy | kyrofa, thats what I thought as well, but they came back saying it didn't work. | 22:54 |
| kyrofa | zyga, can you think of why that wouldn't work? | 22:54 |
| zyga | sorry, I'm semi off now | 23:03 |
| zyga | kyrofa: you probably cannot install a kernel now, not sure | 23:03 |
| zyga | you may need to build an image with it | 23:04 |
| zyga | but I'm just throwing ideas at 4 minutes past midnigth | 23:04 |
| * zyga postpones filing the bug till tomorrow | 23:04 | |
| zyga | jjohansen, jdstrand: https://bugs.launchpad.net/apparmor/+bug/1656121 | 23:12 |
| mup | Bug #1656121: unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace <AppArmor:New> <https://launchpad.net/bugs/1656121> | 23:12 |
| zyga | please tell me if I should provide more data | 23:12 |
| jjohansen | zyga: thanks, I'm just kicking off a kernel build | 23:13 |
| mup | PR snapcraft#1046 opened: godeps plugin: work when GOBIN is set <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1046> | 23:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!