| mup | Bug #1603838 opened: Interface for reading files in /usr <snapd-interface> <Snappy:Triaged> <https://launchpad.net/bugs/1603838> | 00:38 |
|---|---|---|
| mup | Bug #1594324 opened: pulseaudio interface needs access to pulse libraries <Snappy:Confirmed for zyga> <https://launchpad.net/bugs/1594324> | 01:08 |
| skiboy | So I feel uncertain about how apps/snap packages will improve the Linux desktop. Could someone share their reasoning on why apps will improve the user experience? | 02:15 |
| skiboy | Let's take the example of a security update. Let's say that OpenSSL has a critical vulnerability, and 5 different apps are all bundled with it. Wouldn't this mean that all 5 apps need to be updated? | 02:19 |
| skiboy | Especially in third-world countries, where every byte of data matters, wouldn't this be detrimental? | 02:21 |
| skiboy | Do apps actually help the user? Are they worth the bloat? Are they just an easy way out for application developers? | 02:22 |
| Son_Goku | skiboy, in many ways, it's essentially an easy way out | 02:54 |
| Son_Goku | one of the things that the snap/flatpak/appimage/etc model does is return the full burden of security to the upstream author | 02:55 |
| Son_Goku | the blame lays squarely on them | 02:55 |
| skiboy | And I can see the hassle in packaging something for so many different distros... But I feel it will be to the detriment of the end user... | 02:56 |
| Son_Goku | packaging for Linux doesn't have to be so hard, and indeed there are several people working on this problem all the time | 02:56 |
| Son_Goku | but at the end of the day, most people like to cling to enough differences that unifying the underlying architecture that allows for software delivery is not likely to happen | 02:57 |
| Son_Goku | everyone is guilty of this, even myself | 02:57 |
| Son_Goku | in many ways, the development of flatpaks, snaps, appimages, etc. is a signal that we've all thrown in the towel | 02:57 |
| Son_Goku | after nearly 20 years of trying to push for the better model, most of the folks who are commercially invested in Linux are trying to switch to the Windows model of software distribution | 02:59 |
| skiboy | how frustrating | 02:59 |
| === chihchun_afk is now known as chihchun | ||
| Son_Goku | nearly a decade ago, the Linux Standards Base attempted to solve this problem, but some distros never fully agreed to implement the specifications | 03:00 |
| Son_Goku | the Debian family was a rather big opponent back in the day | 03:01 |
| skiboy | but snap packages aren't replacing apt-get, right? I can still easily update my system with one command? | 03:01 |
| Son_Goku | eventually, it will | 03:07 |
| Son_Goku | at least, in Ubuntu | 03:07 |
| Son_Goku | the Ubuntu Snappy Core is the prototype of the future of Ubuntu | 03:07 |
| mup | PR snapd#1662 opened: client, cmd, daemon, osutil: support --yaml and --sudoer flags for create-user <Created by mwhudson> <Conflict> <https://github.com/snapcore/snapd/pull/1662> | 04:48 |
| mup | PR snapd#1663 opened: disallow create-user on classic systems <Created by jaymell> <https://github.com/snapcore/snapd/pull/1663> | 05:53 |
| === PatrizioQON is now known as pbek | ||
| mup | PR snapcraft#719 opened: support dest-subdir on dump plugin <Created by ycheng> <https://github.com/snapcore/snapcraft/pull/719> | 06:50 |
| liuxg | didrocks, I just tried to search for "mysql" and I find a few of them. I want to know how mysql and tomcat are installed in the snap. I think it could be good to have them preassembed somewhhere.. | 07:01 |
| didrocks | liuxg: it seems you just volounteered :) | 07:03 |
| liuxg | didrocks, frankly, I have not tried that yet. I do not know the process for it. | 07:04 |
| didrocks | liuxg: maybe a good opportunity to explore and learn IMHO | 07:04 |
| === faenil is now known as faenil_ | ||
| mup | Bug #1611639 opened: docs/package-names.md is out of sync with the rest of the project <snap-docs> <Snappy:New> <https://launchpad.net/bugs/1611639> | 07:23 |
| mup | Bug #1611641 opened: Running "snap" should produce more helpful output <Snappy:New> <https://launchpad.net/bugs/1611641> | 07:32 |
| mup | PR snapd#1656 closed: snap: do not sort the result of `snap find` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1656> | 07:39 |
| morphis | ogra_: not sure, but a sudo /snap/bin/ubuntu-device-flash core 16 --verbose --channel edge --kernel pi2 --gadget pi3 --os ubuntu-core -o test.img gives me an image where the bootloader can't read the initrd | 08:47 |
| morphis | ogra_: getting https://paste.ubuntu.com/22893704/ | 08:47 |
| ogra_ | morphis, well, is there an initrd.img file in / of your boot partition ? | 09:42 |
| ogra_ | (that should be in a subdir named like the kernel snap) | 09:43 |
| morphis | ogra_: https://paste.ubuntu.com/22896672/ | 09:43 |
| ogra_ | morphis, yeah, thats what i thought ... | 09:44 |
| ogra_ | u-d-f issue | 09:44 |
| morphis | hah | 09:44 |
| morphis | mvo: ^^ | 09:44 |
| ogra_ | (it shoudl copy the initrd and vmlinuz in place and set the snap_kernel var) | 09:44 |
| mvo | morphis: please try "--kernel pi2-kernel" | 09:50 |
| ogra_ | ooh | 09:50 |
| ogra_ | i missed that one ... | 09:50 |
| ogra_ | it should error out there though | 09:50 |
| mvo | morphis: ideally the code would verify that but I'm not sure its worth the work (given that u-d-f will go away soon) | 09:50 |
| mvo | ogra_: yeah, see above | 09:50 |
| ogra_ | yeah | 09:51 |
| morphis | ogra_: was using what you gave me yesterday :-) | 09:55 |
| ogra_ | mvo, hmm, dont you need --devmode for the snapped u-d-f ? (your mail doesnt mention it) | 09:55 |
| morphis | ogra_: you need devmode, yes | 09:56 |
| * ogra_ cant imagine we have loop device access | 09:56 | |
| * ogra_ answers the mail | 09:57 | |
| ogra_ | sigh | 09:57 |
| ogra_ | and i'm blind ! | 09:57 |
| * ogra_ blushes | 09:57 | |
| mup | PR snapd#1664 opened: integration-tests: add update-rollback stress tests <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1664> | 10:03 |
| zyga | http://www.zygoon.pl/2016/08/creating-your-first-snappy-interface.html | 10:05 |
| zyga | :-) | 10:05 |
| * zyga -> coffee | 10:05 | |
| mvo | ogra_: heh, no worries | 10:06 |
| morphis | ogra_, mvo: if I use a local kernel snap do I just have to pass --kernel my.snap or a absolute path? | 10:17 |
| ogra_ | both should work (if the snap is in the same dir at least) | 10:18 |
| timothy | zyga: new failures on snapd-git on archlinux | 10:18 |
| timothy | http://pkgbuild.com/~tredaelli/logs/snapd-git/x86_64.log | 10:19 |
| zyga | timothy: looking | 10:21 |
| zyga | timothy :thanks, I will report this | 10:23 |
| zyga | timothy: I reported https://bugs.launchpad.net/snappy/+bug/1611706 | 10:26 |
| mup | Bug #1611706: Test suite failures on Arch <Snappy:New> <https://launchpad.net/bugs/1611706> | 10:26 |
| mup | Bug #1611706 opened: Test suite failures on Arch <Snappy:New> <https://launchpad.net/bugs/1611706> | 10:27 |
| zyga | dholbach: hey | 10:30 |
| dholbach | hey zyga | 10:30 |
| zyga | dholbach: I'd like to start publishing content on snapcraft.io | 10:31 |
| dholbach | I don't have access to the page | 10:31 |
| zyga | dholbach: how can I do that? | 10:31 |
| dholbach | zyga, https://github.com/ubuntudesign/snapcraft.io | 10:31 |
| zyga | dholbach: thank you | 10:40 |
| dholbach | anytime | 10:40 |
| morphis | mvo, ogra_: ok, using a local kernel snap doesn't wor | 10:41 |
| morphis | it don't end up on the boot partition | 10:42 |
| ogra_ | morphis, hmm, i thought mvo had added a fix for that yesterday | 10:42 |
| morphis | doesn't look like | 10:43 |
| === davidcalle is now known as davidcalle|afk | ||
| joc_ | zyga: nice blog post, thorough and useful i think | 10:49 |
| mvo | morphis, ogra_: sorry, did not manage that yet, will look after lunch, please keep poking, the world is a busy place for me currently, sorry for that | 10:50 |
| ogra_ | no worries | 10:50 |
| === hikiko is now known as hikiko|ln | ||
| morphis | mvo: np | 10:55 |
| mwhudson | ogra_: hey hey did you do that thing about making paths writable yet? | 10:59 |
| ogra_ | mwhudson, bah, crap ... i forgot it ... | 10:59 |
| ogra_ | mwhudson, that was /var/lib/console-conf and /etc/netplan ? | 11:00 |
| mwhudson | ogra_: yes | 11:01 |
| * mwhudson checks his "things he was going to bug ogra_ about list" | 11:01 | |
| mwhudson | ;-p | 11:01 |
| ppisati | does u-d-f accept local files for the gadget / core snap? i know it does the the kernel snap... | 11:02 |
| ppisati | and where can i download those files? | 11:02 |
| mwhudson | you can extract them from a downloaded image ;-) | 11:05 |
| * mwhudson unhelpfuls | 11:05 | |
| zyga | joc_: thank you :) | 11:05 |
| ppisati | i mainly want to avoid: 1) download time 2) development clashes (e.g. something changes in edge that breaks up my stuff) | 11:06 |
| ogra_ | ppisati, it used to, but i'm not sure about the current state, it changed a lot the last days | 11:10 |
| mvo | I look into the kernel sideload bug now | 11:12 |
| mvo | ogra_: sideloading amd64 kernel works, is that a problem with pi2 (uboot) only? | 11:19 |
| ogra_ | mvo, yeah, i only saw it on amr builds (dragonboard and pi2/3) | 11:19 |
| ogra_ | *arm | 11:19 |
| mvo | aha, ok | 11:20 |
| ogra_ | [ 6.377542] smsc95xx v1.0.4 | 11:23 |
| ogra_ | [ 6.435520] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-3f980000.usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:c9:2b:03 | 11:23 |
| ogra_ | [ 7.901142] smsc95xx 1-1.1:1.0 enxb827ebc92b03: renamed from eth0 | 11:23 |
| ogra_ | hmm | 11:23 |
| ogra_ | ppisati, any idea why the kernel would ignore net.ifnames=0 ? | 11:23 |
| ppisati | ogra_: it's not the kernel | 11:25 |
| ppisati | ogra_: hold on | 11:25 |
| ppisati | https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1593379 | 11:25 |
| mup | Bug #1593379: systemd 229-4ubuntu6 ignores net.ifnames=0 on USB or /etc/udev/rules.d/80-net-setup-link.rules being a /dev/null symlink <verification-failed> <systemd | 11:25 |
| mup | (Ubuntu):Fix Released by pitti> <systemd (Ubuntu Xenial):In Progress by pitti> <systemd (Debian):Fix Released> <https://launchpad.net/bugs/1593379> | 11:25 |
| ppisati | fixed in yakkety, still open in xenial | 11:25 |
| * ppisati goes for lunch, back later | 11:26 | |
| ogra_ | ppisati, ah ... well, that wasnt systemd but the smsc95xx driver printing the above | 11:30 |
| ogra_ | would systemd change it back ? (i would expect the kernel to not rename it at all) | 11:31 |
| === chihchun is now known as chihchun_afk | ||
| === hikiko|ln is now known as hikiko | ||
| mvo | ppisati, ogra_: can you please try r4 of u-d-f from the store? it should fix the kernel sideload bug | 12:22 |
| * ogra_ just tested the pi3 image with the new ubuntu-core from the store, looks fine | 12:22 | |
| ogra_ | i'll test a sideloaded kernel next | 12:23 |
| ogra_ | hmmm .... hmmmmm ... | 12:26 |
| ogra_ | morphis, did you try to build an armhf snap for u-d-f too ? | 12:27 |
| ogra_ | i wonder if you could build an image on the pi or dragonboard on an all-snap system :) | 12:27 |
| josepht | sergiusens: didrocks brings up a good point in the sub-parts mailing list thread regarding older versions of snapcraft needing the still namespaced part names. I think we can work around it by having the namespaced part names explicitly in the wiki and updating the origins. | 12:42 |
| josepht | i.e. parts: [desktop/gtk2, desktop/gtk3, ...] and another entry with "parts: [desktop-gtk2, desktop-gtk3, ...] | 12:43 |
| jdstrand | noise][: that's fine. I've got a meeting in a few minutes but suspect that next commit in less than 2 hours | 12:45 |
| morphis | ogra_: no :-) | 12:54 |
| liuxg | has anyone ever snapped tomcat into snap? | 12:57 |
| ogra_ | yeah, in 15.04 ... not sure if there is a s16 snap | 12:58 |
| liuxg | ogra_, would you please show me the project? thanks | 12:59 |
| ogra_ | no idea where that lives | 13:01 |
| liuxg | ogra_, a customer is using apache, tomcat, mysql, java for a server on ubuntu core. I am trying to find out how we can package the stuff into a snap. | 13:02 |
| ogra_ | i only remember someone packaging it | 13:02 |
| ogra_ | iirc either asac or lool | 13:02 |
| liuxg | asac, lool, have you every packaged tomcat into a snap? a customer is trying to build a apache server with tomcat. thanks | 13:03 |
| ogra_ | (probably asking on gitter in the snappy-playpen channel makes more sense though ) | 13:04 |
| ogra_ | didrocks, ^^^ didnt mosquitto use tomcat ? | 13:05 |
| ogra_ | iirc you worked on that | 13:05 |
| === mterry_ is now known as mterry | ||
| liuxg | ogra_, mosquitto does not use tomcat, it uses MQTT to do thaht. | 13:06 |
| didrocks | yeah, only mqtt AFAIK | 13:10 |
| liuxg | didrocks, ogra_, if tomcat is not in the official ubuntu archive, we cannot install it directly from the debian packages, right? we have to use the source code to build it, right? | 13:11 |
| ogra_ | well, arent there tarballs with binaries ? | 13:12 |
| ogra_ | i see tomcat in the archive though | 13:13 |
| ogra_ | 7 and 8 | 13:14 |
| ppisati | ogra_: the kernel is printing it because the rename function (dev_change_name()) is invoked through an ioctl() | 13:16 |
| ppisati | ogra_: if you try with the xenial's release systemd package, you won't hit that | 13:16 |
| didrocks | liuxg: you can always at worse download the content of binaries and uncompress while using the copy/dump plugins | 13:17 |
| ogra_ | ppisati, ok, i was just curious since that happens before init even runs i think | 13:17 |
| liuxg | didrocks, the thing is that we need to copy to the right place in the snap. we have to know where the files should go. | 13:19 |
| lool | liuxg: Hi, here's the sample snap I did with Tomcat a long while ago https://github.com/snapcore/snapcraft/blob/master/demos/tomcat-maven-webapp/snapcraft.yaml | 13:20 |
| lool | liuxg: it is not very fancy, but it worked; let me know how it goes | 13:20 |
| didrocks | liuxg: indeed | 13:21 |
| lool | liuxg: I'm travelling this week, so a bit hard to reach | 13:21 |
| liuxg | lool, many thanks for your help. I will take a look at it. Have a good trip! | 13:21 |
| lool | thanks | 13:22 |
| liuxg | didrocks, lool, strange, "dump" is not listed when I use "snapcraft list-plugins". is this a bug? | 13:23 |
| lool | liuxg: It's the first time I hear about it; I think this example was modified when this plugin landed in snapcraft | 13:23 |
| didrocks | liuxg: it will be available with the next version of snapcraft (which is in -proposed right now) | 13:23 |
| ogra_ | dump is the new name for the copy plugin i think | 13:24 |
| liuxg | didrocks, my current snapcraft version is 2.13.1, what will be next release? | 13:25 |
| ogra_ | .14 | 13:25 |
| liuxg | ogra_, do you mean that I can use "copy" to replace it? | 13:25 |
| ogra_ | yes | 13:25 |
| ogra_ | or just look at an older version of the branch :) | 13:26 |
| liuxg | ogra_, then in the example https://github.com/snapcore/snapcraft/blob/master/demos/tomcat-maven-webapp/snapcraft.yaml#L17, it does not specify the destination, will it work? | 13:26 |
| liuxg | ogra_, sorry, this is the line https://github.com/snapcore/snapcraft/blob/master/demos/tomcat-maven-webapp/snapcraft.yaml#L22 | 13:27 |
| liuxg | didrocks, do you know how I can make use of the latest snapcraft (-proposed)? my snapcraft is from the stable channel so far. | 13:28 |
| didrocks | liuxg: you can just wget the package on launchpad and install it manually | 13:28 |
| didrocks | with dpkg -i | 13:28 |
| ogra_ | liuxg, this is the snapcraft.yaml from before the rename (seems it wasnt only copy that got renamed to dump) https://github.com/snapcore/snapcraft/blob/f0a19ebccfa3f0502b792095d4b0edae4e04eb68/demos/tomcat-maven-webapp/snapcraft.yaml | 13:29 |
| liuxg | didrocks, OK, I will have a try. thanks. previously, I just directly installed it from the source, and I messed up everything. | 13:30 |
| didrocks | yeah, you can go this way, it's safer :) | 13:30 |
| liuxg | ogra_, thanks for your help. yeah, it looks different | 13:31 |
| liuxg | lool, what is the purpose of the file ".travis.yml" in the project https://github.com/lool/snappy-mvn-demo/blob/master/.travis.yml? thanks | 13:47 |
| lool | liuxg: it's to trigger a travis build when something gets pushed or when a pull request is made | 13:48 |
| lool | liuxg: see travis-ci.org | 13:48 |
| lool | liuxg: I dont think it worked correctly for that project though | 13:48 |
| liuxg | lool, I just tried to compile it, it failed. I compiled it using the its previous version http://paste.ubuntu.com/22912200/ | 13:49 |
| liuxg | lool, the error message is like http://paste.ubuntu.com/22912252/ | 13:50 |
| liuxg | didrocks, where did you find the binaries for the snapcraft on launchpad? I found a site https://launchpad.net/snapcraft/trunk, but I did not get the release file? thanks | 14:00 |
| didrocks | liuxg: https://launchpad.net/ubuntu/+source/snapcraft/2.14/+build/10589180 | 14:00 |
| didrocks | see "built files" | 14:00 |
| liuxg | didrocks, yes, I saw it. thanks | 14:01 |
| ogra_ | ogra@anubis:~/datengrab/images/snappy$ sudo snap refresh --channel=beta ubuntu-device-flash | 14:02 |
| ogra_ | error: cannot refresh "ubuntu-device-flash": snap "ubuntu-device-flash" has no updates available | 14:02 |
| ogra_ | mvo, ^^^ did you publish the new u-d-f ? | 14:02 |
| ogra_ | oh | 14:02 |
| ogra_ | ignore that ... needs --devmode too | 14:03 |
| ogra_ | uuuh | 14:03 |
| ogra_ | error: cannot perform the following tasks: | 14:03 |
| ogra_ | - Setup snap "ubuntu-device-flash" (4) security profiles (cannot setup apparmor for snap "ubuntu-device-flash": cannot load apparmor profile "snap.ubuntu-device-flash.ubuntu-device-flash": cannot load apparmor profile: exit status 10 | 14:03 |
| * didrocks was going to suggest that | 14:03 | |
| ogra_ | apparmor_parser output: | 14:03 |
| ogra_ | ) | 14:03 |
| mvo | ogra_: wuut | 14:04 |
| mvo | ogra_: how can apparmor fail for a devmode snap :( | 14:04 |
| mvo | ogra_: if the file is still there, can you pastebinit ? (I guess its not :/ | 14:05 |
| ogra_ | now ... that didbnt go so well ... calling u-d-f anyway after that error had-locked my machine | 14:07 |
| * ogra_ removes and re-installs | 14:08 | |
| ogra_ | that looks better | 14:08 |
| liuxg | lool, ogra_, I have upgraded my snapcraft to 2.14, but I still get the same error when I tried to build the tomcat demo example https://github.com/snapcore/snapcraft/tree/master/demos/tomcat-maven-webapp. the error message is like http://paste.ubuntu.com/22913740/, do I miss anything there? | 14:09 |
| jdstrand | mvo: note, the apparmor policy is wholly present with --devmode-- all that is different is the complain flag | 14:10 |
| zyga | jdstrand: hey, I posted another interface article on my blog, feedback welcome :-) | 14:10 |
| zyga | mvo: hmm? | 14:10 |
| mvo | ogra_: that is still pretty terrible, this is snapd 2.11? | 14:11 |
| mvo | jdstrand: oh, ok | 14:11 |
| zyga | mvo: devmode can still fail, it's just another profile | 14:11 |
| jdstrand | mvo: so if there is an error in the policy then it will fail to parse. also, if this is done on a machine that doesn't have an updated parser for newer rules (like unix), it will fail to parse | 14:11 |
| mvo | zyga: see above, ogra_ installed an update of ubuntu-device-flash and the install aborted with an exit 10 | 14:11 |
| ogra_ | ogra@anubis:~/datengrab/images/snappy$ snap --version | 14:11 |
| ogra_ | snap 2.11+0.16.04 | 14:11 |
| ogra_ | snapd 2.11+0.16.04 | 14:11 |
| ogra_ | series 16 | 14:11 |
| ogra_ | ubuntu 16.04 | 14:11 |
| jdstrand | is this by chance running on a trusty machine? | 14:11 |
| ogra_ | nope | 14:11 |
| ogra_ | there is no snap on trusty :) | 14:11 |
| mvo | jdstrand: well, I did not do anything with the policy | 14:11 |
| mvo | jdstrand: this is a quick-n-dirty devmode snap of ubuntu-device-flash | 14:12 |
| zyga | mvo: we should see exactly what apparmor_parser said | 14:12 |
| ogra_ | it worked fine after snap remove and snap install | 14:12 |
| zyga | ogra_: can you pastebin the profile from /var/lib/snapd/apparmor/profiles please | 14:12 |
| ogra_ | zyga, i fear thats gone now ... but indeed i can | 14:12 |
| zyga | mvo: maybe there's a bug in some of the intefaces that causes this to fail | 14:12 |
| ogra_ | (i mean the broken one is gone) | 14:12 |
| ogra_ | http://paste.ubuntu.com/22914044/ | 14:13 |
| zyga | ogra_: this looks like a efault template | 14:13 |
| mvo | ogra_: anything in snap changes or snap change XX (nr) that might give a clue? | 14:13 |
| mvo | zyga: it is | 14:14 |
| zyga | ogra_: if that fails then all the snaps will fail the same way | 14:14 |
| zyga | ogra_: can you install hello-world snap please? | 14:14 |
| ogra_ | mvo, http://paste.ubuntu.com/22914167/ | 14:14 |
| jdstrand | artmello_: hey | 14:15 |
| artmello_ | jdstrand: hey | 14:15 |
| ogra_ | zyga, installed | 14:16 |
| === artmello_ is now known as artmello | ||
| jdstrand | artmello_: are you planning on snapping the thumbnailer service or assuming it will be present on the system? | 14:16 |
| mvo | jdstrand: does exit-code 10 has any meaning (context is http://paste.ubuntu.com/22914167/) | 14:16 |
| artmello | jdstrand: snapping it. I have an untested snap of it but I was thinking about fixing the interface first | 14:17 |
| artmello | jdstrand: but I can start using the snap thumbnailer during these tests | 14:17 |
| jdstrand | artmello: ok, so 'classic' is the traditional Ubuntu desktop system and interfaces that access those services need different policy than those that are services as snaps | 14:18 |
| artmello | jdstrand: ok | 14:18 |
| jdstrand | artmello: because you are snapping thumbnailer, you don't have to worry about classic at this time | 14:18 |
| artmello | jdstrand: right | 14:19 |
| jdstrand | artmello: so, yes, do the ConnectedSlotAppArmor stuff I mentioned in privmsg. when testing, you'll want to remove the thumbnailer service deb and install the thumbnailer service snap | 14:19 |
| jdstrand | (so the snap can bind to the dbus interface, etc) | 14:20 |
| === davmor2_ is now known as davmor2 | ||
| jdstrand | artmello: but you'll need to adjust the thumbnailer to not do the security label check any more (since it doesn't have to with interface connections) | 14:20 |
| artmello | jdstrand: right, will change thumbnailer as you suggested | 14:21 |
| jdstrand | artmello: (or again, if sharing codesbases for the thumbnailer with click, short-circuit with the snap. check I mentioned) | 14:21 |
| artmello | jdstrand: ok, thx! I undertood it better now. Will apply the changes and see how it goes | 14:24 |
| zyga | ogra_: hmmmm so if that doesn't fail then I have no idea | 14:24 |
| zyga | ogra_: is the problem reproducible? | 14:24 |
| ogra_ | zyga, dunno, i can tell you the next time i upgrade something in --beta with --devmode from the store i guess | 14:24 |
| kyrofa | ogra_, mvo can we release the OS snaps into staging as part of our process as well? | 14:25 |
| sergiusens | josepht we can just pick up another cache file | 14:25 |
| jdstrand | mvo: '10' doesn't mean much to me. that seems to be ECHILD... | 14:25 |
| ogra_ | perhaps mvo can upload a no-change snap of u-d-f so i can re-test (though perhaps that should wait til after the meeting, i dont want to have to hit the reset button during meeting :)) | 14:25 |
| ogra_ | kyrofa, i just released a set today | 14:26 |
| jdstrand | what is the snap.yaml of ubuntu-device-flash? | 14:26 |
| kyrofa | ogra_, ah, into staging as well? | 14:26 |
| mvo | kyrofa: staging? you mean candidate? | 14:26 |
| kyrofa | mvo, no, the staging server | 14:26 |
| kyrofa | mvo, staging store, whatever it's called | 14:26 |
| mvo | kyrofa: oh, sorry. hm, yes we can :) | 14:26 |
| ogra_ | kyrofa, i'm waiting for jdstrand's review tools fix to land to see how the auto-landing goes ... but i think we still need to manually hit the publish button | 14:26 |
| kyrofa | mvo, if you setup a clean machine and point it to staging, there's no OS snap to pull down so you can't install anything :) | 14:26 |
| kyrofa | mvo, easy workaround, but if that's something we can automate it'd be useful | 14:27 |
| mvo | kyrofa: I shared it with you, you can now just download it directly from the real store and upload to staging as you need | 14:28 |
| kyrofa | mvo, ah, super useful thank you! | 14:28 |
| mvo | kyrofa: +1 for automation, we are still working on that, its still very manual right now (manual approve, manual publish, lots of button clicks :/ | 14:28 |
| ogra_ | kyrofa, i guess thats also a cjwatson question if LP can offer uploads to staging | 14:29 |
| ogra_ | (if there is a way i'll happily add a parallel ubuntu-core build, thats trivial) | 14:29 |
| ogra_ | reading pi2-kernel_x1.snap/kernel.img | 14:31 |
| ogra_ | ** Unable to read file pi2-kernel_x1.snap/kernel.img ** | 14:31 |
| ogra_ | reading pi2-kernel_x1.snap/initrd.img | 14:31 |
| ogra_ | ** Unable to read file pi2-kernel_x1.snap/initrd.img ** | 14:31 |
| ogra_ | Bad Linux ARM zImage magic! | 14:31 |
| kyrofa | ogra_, oh, good point | 14:31 |
| ogra_ | mvo, ^^^ | 14:31 |
| cjwatson | ogra_: only from LP staging | 14:32 |
| ogra_ | ah, well, then i should be able to set something up (i have to check if i still have staging access) | 14:32 |
| cjwatson | staging access isn't a special thing | 14:33 |
| cjwatson | but it does require a separate staging SSO account | 14:33 |
| cjwatson | and staging LP isn't up all the time | 14:33 |
| mvo | ogra_: can you run "file pi2-kernel_x1.snap/kernel.img" (and the same for initrd.img? | 14:33 |
| ogra_ | ogra@anubis:~/datengrab/images/snappy$ ls /media/ogra/writable/system-data/snap/pi2-kernel/ | 14:33 |
| ogra_ | unset | 14:33 |
| ogra_ | ogra@anubis:~/datengrab/images/snappy$ | 14:33 |
| mvo | ogra_: and what commandline did you use? I will try to reproduce | 14:33 |
| ogra_ | same issue as before | 14:33 |
| mvo | ogra_: hm, hm | 14:34 |
| ogra_ | and no kernel/initrd in system-boot at all | 14:34 |
| ogra_ | ogra@anubis:~/datengrab/images/snappy$ sudo /snap/bin/ubuntu-device-flash core 16 --channel edge --gadget pi3 --kernel pi2-kernel_4.4.0-1019-raspi2_armhf.snap --os ubuntu-core -o test-pi3.img | 14:36 |
| ogra_ | that was what i used for building ... the kernel was manually downloaded from the store | 14:36 |
| mup | PR snapcraft#719 closed: support dest-subdir on dump plugin <Created by ycheng> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/719> | 14:38 |
| === matiasb1 is now known as matiasb | ||
| stokachu | is network-control the only plug i need so that my snap can create a network bridge? | 14:51 |
| ogra_ | well, you probably also want to use thenetwork .. so the "network" plug would also be handy in that case | 14:51 |
| stokachu | ok, problem is when i set those 2 and attempt to run my snap it just errors with "Bad system call" | 14:52 |
| stokachu | this is running in strict mode | 14:53 |
| stokachu | https://www.irccloud.com/pastebin/F04R1oh6/ | 14:54 |
| stokachu | thats my log output | 14:54 |
| jdstrand | stokachu: assuming this is amd64, you need network-bind (scmp_sys_resolver 49 shows as bind) | 14:55 |
| jdstrand | stokachu: no if you aren't actually binding to a network port, then the network-control interface should probably include bind | 14:55 |
| jdstrand | s/no/now/ | 14:55 |
| stokachu | jdstrand: yea im just creating a bridge for my lxd containers to use | 14:56 |
| jdstrand | stokachu: can you file a bug and add the 'snapd-interface' tag with a simple reproducer for needing bind? | 14:58 |
| stokachu | jdstrand: sure thing | 14:59 |
| jdstrand | stokachu: and mention the workaround is to use 'network-bind' | 14:59 |
| jdstrand | stokachu: thanks! :) | 14:59 |
| stokachu | jdstrand: np, building now and testing to make sure it won't fail | 14:59 |
| sergiusens | elopio do you want to tackle https://bugs.launchpad.net/snapcraft/+bug/1611498 ? | 15:00 |
| mup | Bug #1611498: snapcraft fails install using virtualenv instructions <Snapcraft:Triaged> <https://launchpad.net/bugs/1611498> | 15:00 |
| sergiusens | next week | 15:01 |
| sergiusens | or maybe josepht as you got this going in the first place ^ | 15:01 |
| stokachu | jdstrand: cool! works | 15:01 |
| josepht | sergiusens: I can take care of that | 15:02 |
| josepht | elopio: ^ | 15:02 |
| liuxg | sergiusens, I just tried to build the demo example at https://github.com/snapcore/snapcraft/tree/master/demos/tomcat-maven-webapp, there was an error. I do not know how to correct the problem for it. I have upgraded my snapcraft to 2.14 already. thanks | 15:02 |
| jdstrand | stokachu: nice! :) | 15:02 |
| dragly | is http://search.apps.ubuntu.com down? | 15:04 |
| ppisati | Getting details for ubuntu-core | 15:13 |
| ppisati | Expecting value: line 1 column 1 (char 0) | 15:13 |
| ppisati | ... | 15:13 |
| ppisati | snapcraft just returned this while trying to fecth ubuntu-core | 15:14 |
| OerHeks | dragly, there is an update going on, launchpad is down too. | 15:14 |
| ogra_ | ppisati, funny error ... and so descriptive :P | 15:14 |
| dragly | OerHeks: Okay. Thanks :) | 15:14 |
| ppisati | ogra_: :( | 15:14 |
| ppisati | i hope is connected to the lp / store/ etc downtime | 15:14 |
| ogra_ | ppisati, thats the kernel plugin trying to get the initrd from the store ? | 15:14 |
| ahasenack | is it true you cannot snap an app that starts as root and then drops its privileges? | 15:15 |
| ppisati | ogra_: yep, to download the ubuntu-core snap i think | 15:15 |
| ahasenack | I'm checking https://developer.ubuntu.com/en/snappy/build-apps/debug/#common-problems | 15:16 |
| ahasenack | the switch from root to unprivileged user (or any other user) is blocked? | 15:16 |
| ogra_ | ahasenack, where to would it drop its privs ? | 15:16 |
| ogra_ | there are no users | 15:17 |
| ahasenack | is that the reason? | 15:17 |
| ahasenack | or is the set?uid call blocked?/ | 15:17 |
| ogra_ | asnd there is no ability to create any from a snap | 15:17 |
| ahasenack | it could be a default user from /etc/passwd | 15:17 |
| ogra_ | setuid gets stripped out by snapcraft at build time | 15:17 |
| ahasenack | shipped in the base system | 15:17 |
| ogra_ | and daemons/services always run as root | 15:17 |
| ahasenack | I meant the syscall, not the setuid bit on a file | 15:17 |
| ogra_ | yeah,m i think thats blocked, together with fchown and others | 15:18 |
| ahasenack | not in the real world, there good services run as unprivileged users. I understand apparmor can confine root, sure | 15:18 |
| niemeyer | ahasenack: A couple of aspects to that: | 15:21 |
| niemeyer | ahasenack: snapd can easily mediate any interactions around that, including privilege dropping | 15:22 |
| niemeyer | ahasenack: So if there are requirements, we can cook the proper interface lifting the exact allowances the application would need for doing its job | 15:22 |
| niemeyer | ahasenack: Unfortunately and ironically, "dropping" privileges is often done with system calls that allows *gaining* privileges | 15:23 |
| sergiusens | ppisati please log a bug for that :-) | 15:23 |
| niemeyer | ahasenack: So although the app intent is good, relinquishing access to certain things, from a system perspective it may not be advantageous to allow even the initial phase of the application to do those actions | 15:24 |
| niemeyer | ahasenack: So, YMMV.. I wouldn't strongly prescribe anything at this point.. I know you are very security-mindful, and if you have suggestions or would like to research about how much to give and how much to take, that'd be very welcome | 15:25 |
| mup | Bug #1611819 opened: implement a way for daemons to play audio <Snappy:New> <https://launchpad.net/bugs/1611819> | 15:26 |
| elopio | sergiusens: pong. | 15:26 |
| jdstrand | ahasenack: we are going to support privilege dropping, we first need snap-confine in xenial-updates, then we'll allow something, perhaps priv dropping to 'daemon'. later we might allow requesting a uid and/or gid and dropping to that (that would be farther out) | 15:26 |
| niemeyer | jdstrand: Nice | 15:27 |
| jdstrand | I feel like I keep talking about snap-confine landing. fingers crossed it will be soon :) | 15:28 |
| jdstrand | that said, I have several things on my plate to get to before that, so that's ok | 15:29 |
| jdstrand | noise][: hey, Canonical irc seems down so mentioning here | 15:36 |
| jdstrand | noise][: r706 is ready to pull. that, among other things, will do what ogra_ asked me to address wrt auto-approve of the ubuntu-core snap | 15:37 |
| kyrofa | jdstrand, yep, lost it here too | 15:37 |
| ogra_ | jdstrand, that includes the confinement complaint too ? | 15:39 |
| ogra_ | (or was that not causing a block) | 15:39 |
| jdstrand | ogra_: can you give me the link to the snap that had that? | 15:40 |
| ogra_ | if the store lets me in :P | 15:40 |
| jdstrand | ogra_: the issue was 'confinement' not being present? | 15:40 |
| ogra_ | no, being present in a non "app" snap | 15:41 |
| joc_ | jdstrand: hi, i'm trying to confirm if the udev tagging for cgroup access is working for me as discussed yesterday, i'm finding that i get access to everything matched by /dev/** though | 15:41 |
| ogra_ | https://myapps.developer.ubuntu.com/dev/click-apps/4142/rev/176/ | 15:41 |
| mup | PR snapcraft#679 closed: add multiple generator script options to autotools <Created by apachelogger> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/679> | 15:41 |
| ogra_ | jdstrand, the messages are: | 15:41 |
| ogra_ | 'confinement' should only be specified with 'type: app' lint-snap-v2_confinement_valid | 15:41 |
| ogra_ | (NEEDS REVIEW) type 'os' not allowed lint-snap-v2_snap_type_redflag | 15:41 |
| jdstrand | ogra_: I fixed the second | 15:42 |
| ogra_ | sadly snapcraft forcefully adds "confinement: strict" to all builds regardless of type | 15:42 |
| joc_ | jdstrand: do i need to check that i have a particular version of snap-confine running? | 15:42 |
| ogra_ | can we have the first one not be a blocker ? | 15:42 |
| jdstrand | ogra_: ok, yeah, I didn't fix the first one. | 15:42 |
| sergiusens | ogra_ sadly there is no requirement for it to be any different either ;-) | 15:42 |
| jdstrand | noise][: give me a few minutes for r707 | 15:42 |
| ogra_ | sergiusens, well, it will make all auto uploads for os or kernel snaps fail atm | 15:42 |
| jdstrand | joc_: use snap-confine from xenial-proposed | 15:43 |
| ogra_ | sergiusens, but yeah, it is completely ignored by snapd at install or image build time | 15:43 |
| jdstrand | confinement makes no sense with the core snap | 15:43 |
| sergiusens | ogra_ a requirement means that all interested members of the party should comply for things to work though ;-) | 15:43 |
| ogra_ | jdstrand, agreed, but it also doesnt do any harm since it is ignored everywhere | 15:43 |
| joc_ | jdstrand: i'm using an all-snap image to test on device | 15:43 |
| jdstrand | I'm just saying why the test is what it is | 15:44 |
| ogra_ | jdstrand, i'd be fine with a warning as long as it doesnt block the upload | 15:44 |
| jdstrand | ogra_: I'll fix it. I'm not saying I won't, just saying snapcraft imho shouldn't adding meaningless yaml | 15:44 |
| ogra_ | jdstrand, agreed, i blame kyrofa and sergiusens :P | 15:45 |
| sergiusens | jdstrand ogra_ if it makes no sense a bug report is enough | 15:45 |
| ogra_ | i think i opened one | 15:45 |
| * ogra_ goes digging | 15:45 | |
| sergiusens | ogra_ I blame you for not doing a full end to end analysis ;-) | 15:45 |
| jdstrand | joc_: I haven't used all snaps systems in ages cause of all the churn. I don't know if it is using snap-confine or not. does /usr/lib/snapd/snap-confine exist? | 15:45 |
| ogra_ | sergiusens, bug 1607459 | 15:45 |
| mup | Bug #1607459: type:os should prevent adding "confinement" to the snap.yaml <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1607459> | 15:46 |
| dholbach | all rightie - I call it a day - see you in two weeks! :-) | 15:46 |
| sergiusens | kyrofa ^ | 15:46 |
| ogra_ | i should change that to "os and kernel" | 15:46 |
| sergiusens | want to take that confinement thing? | 15:46 |
| * ogra_ hugs sergiusens | 15:46 | |
| sergiusens | ogra_ there you go, bug only said os ;-) | 15:46 |
| ogra_ | heh | 15:46 |
| sergiusens | ogra_ what about gadget? | 15:46 |
| ogra_ | yeah, that too i guess | 15:46 |
| sergiusens | the kernel can have hooks | 15:46 |
| jdstrand | well | 15:46 |
| joc_ | jdstrand: no it's not in my image | 15:47 |
| jdstrand | it is less clear for kernel and gadget | 15:47 |
| sergiusens | don't you think running the hooks in devmode might be a good thing? | 15:47 |
| ogra_ | i doubt we will have gadget auto-uploads though | 15:47 |
| sergiusens | jdstrand which is why I bring it up :-) | 15:47 |
| sergiusens | hooks change everything | 15:47 |
| ogra_ | these things are usually one-time uploads that do not change very frequently once they are stable | 15:47 |
| jdstrand | I don't have an answer for those. my understanding is for both they may have parts that are confined | 15:47 |
| jdstrand | at some point | 15:47 |
| jdstrand | but I don't know the status today | 15:47 |
| sergiusens | jdstrand also, once we have the core for say fedora, won't confinement make a little sense at least for the os snap in case the confinement part is not fully implemented | 15:48 |
| sergiusens | but that is all zyga's grand scheme of things thing ^ | 15:48 |
| jdstrand | joc_: can you give me ~20 minutes then I can give you my full attention? | 15:48 |
| joc_ | jdstrand: sure | 15:48 |
| jdstrand | but... ogra_ what needs to happen to make snap-confine in the core snap instead of ubuntu-core-launcher? snap-confine landing in xenial-proposed and because ubuntu-core-launcher is a transitional package it will pull in snap-confine? | 15:50 |
| ogra_ | jdstrand, we need to drop u-c-l and add snap-confine to the "seed" (which we dont really have, it is a hardcoded package list in livecd-rootfs) | 15:51 |
| jdstrand | ogra_: I'm somewhat concerned if that is the case because snap-confine continues to not make it through SRU and joc_ and his team are going to need this for their testing | 15:51 |
| ogra_ | (bacuse you cant change seeds for released LTSes) | 15:51 |
| jdstrand | ogra_: will that process pull in from xenial-proposed? | 15:51 |
| kyrofa | sergiusens, sure, assign that one to me, I'll put it on my snapcraft backlog | 15:51 |
| ogra_ | you mean move it to the archive ? | 15:51 |
| ogra_ | thats an archive admin task ... | 15:52 |
| ogra_ | totally unrelated ot any seeds or dependencies | 15:52 |
| ogra_ | moving it to main once it did move to the archive proper will need a dependency ... but getting out out of proposed has nothing to do with this | 15:52 |
| jdstrand | ogra_: no. well, I don't know. joc_ and his team will need snap-confine in the image ideally now so they can test with the real bits that will be in rtm. it is in xenial-proposed. is there a way to make that happen? | 15:53 |
| sergiusens | kyrofa just make sure to bring up the conflicts about type: core, gadget and kernel and if confinement makes sense; also think about core coming from say another distro (think about the built-on tag we discussed in Heildelberg) and think about the fact that some cores might not implement all the confinement primitives (where in that case the core snap would be devmode I guess) | 15:53 |
| jdstrand | ogra_: I'm talking about core snap, not classic | 15:53 |
| jdstrand | not sure if that makes a difference | 15:53 |
| sergiusens | kyrofa more of a research first implement later | 15:53 |
| ogra_ | jdstrand, let me check ... | 15:54 |
| ogra_ | Get:77 http://ports.ubuntu.com/ubuntu-ports xenial-proposed/main armhf snap-confine armhf 1.0.38-0ubuntu0.16.04.4 [19.6 kB] | 15:54 |
| ogra_ | https://launchpadlibrarian.net/278185694/buildlog_snap_ubuntu_xenial_armhf_ubuntu-core_BUILDING.txt.gz | 15:54 |
| kyrofa | sergiusens, indeed, good points | 15:54 |
| kyrofa | I'll mention in standup tomorrow | 15:54 |
| ogra_ | seems it is alreayd pulled in but someone forgot to delete an older version from the image PPA | 15:54 |
| sergiusens | kyrofa let me just add that to the bug | 15:54 |
| ogra_ | OH, wait | 15:54 |
| ogra_ | Get:77 http://ports.ubuntu.com/ubuntu-ports xenial-proposed/main armhf snap-confine armhf 1.0.38-0ubuntu0.16.04.4 [19.6 kB] | 15:54 |
| ogra_ | yeah, it comes from porposed ... the ppa just confused me | 15:55 |
| jdstrand | joc_: ^ perhaps you can work with ogra_ on obtaining the correct core snap? | 15:55 |
| ogra_ | joc_, jdstrand so it is in the last edge ubuntu-core | 15:55 |
| jdstrand | ogra_: great, thanks! :) | 15:55 |
| sergiusens | ogra_ don't log ubuntu bugs! | 15:55 |
| sergiusens | ogra_ those get ignored by us | 15:55 |
| ogra_ | btw, daily builds and build logs are at https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core | 15:55 |
| ogra_ | sergiusens, so ignorant :P | 15:56 |
| sergiusens | this is why we missed it | 15:56 |
| ogra_ | sergiusens, what if people follow the distro guidelines for filing bugs then ? | 15:56 |
| ogra_ | (which tell you to use "ubuntu-bug snapcraft" ) | 15:56 |
| sergiusens | ogra_ the distro guys should then link them ;-) | 15:56 |
| joc_ | jdstrand: ogok thanks, i can try and use the recent ubuntu-device-flash to spin a new image | 15:56 |
| sergiusens | ogra_ as any other upstream | 15:56 |
| ogra_ | sergiusens, which distro guys would look at them, i dont hink anyone is subscribed to the package | 15:57 |
| ogra_ | yxou would need a responsible team that subscribes to them | 15:57 |
| sergiusens | ogra_ and that is why so many bugs get unresolved ;-) | 15:57 |
| ogra_ | yeah | 15:57 |
| ogra_ | someone needs to take them | 15:57 |
| dragly | zyga: I might be using it wrong, but running snapd-hacker-toolbelt.busybox ls /var/lib/snapd/lib/gl/ gives me "Permission denied". Could that be the issue, or do I have to give the snapd-hacker-toolbelt some permission before it can do ls? | 15:57 |
| ogra_ | since ubuntu users are told to zuse ubuntu-bug by all docs we have | 15:57 |
| zyga | dragly: connect the opengl interface | 15:59 |
| sergiusens | ogra_ in any case, if I look at the bugs on the package I see most of them are logged by distro people. All others consuming snapcraft drt ;-) | 15:59 |
| zyga | dragly: by default it is probably off-limits | 15:59 |
| sergiusens | ogra_ more reason to move to a snap ASAP as well ;-) | 15:59 |
| ogra_ | sergiusens, well, you should talk to foundations i guess to subscribe to the distro bugs then | 15:59 |
| dragly | Can I do that after installing it or do I need to rebuild the snapd-hacker-toolbelt snap? | 16:00 |
| ogra_ | sergiusens, will a snapcraft snap work in classic mode on an all snap image ? | 16:00 |
| ogra_ | mvo, ^^^ do you know ? | 16:00 |
| ogra_ | (thats most likely the biggest reason to use a classic shell on an all-snap image) | 16:00 |
| sergiusens | ogra_ nah, I'll let you do it; the package bugs are pretty much the same as someone mentioning bugs in a mailing list, forum or redit | 16:00 |
| sergiusens | ogra_ we won't need classic | 16:01 |
| sergiusens | ogra_ all we will need is lxd | 16:01 |
| ogra_ | ok | 16:01 |
| mvo | sergiusens: but we can use classic until lxd is ready? | 16:01 |
| * sergiusens is feeling feisty today | 16:02 | |
| sergiusens | mvo yeah, just like before it went away :-) | 16:02 |
| dragly | zyga: Or is editing snaps directly in the /snap folder okay while debugging? | 16:02 |
| mup | PR snapd#1665 opened: many: do not require root for `snap prepare-image` <Created by mvo5> <https://github.com/snapcore/snapd/pull/1665> | 16:03 |
| ogra_ | mvo, well, i can still imagine that people using the classic shell want to use binaries from installed snaps in there, we should plan for that | 16:03 |
| ogra_ | (it isnt like we dont have everything we need in there already) | 16:04 |
| ogra_ | (but i doubt the setup is ready OOTB currently) | 16:04 |
| mup | Bug #1611837 opened: all-snaps: Boot breaks on reset in VirtualBox <Snappy:New> <https://launchpad.net/bugs/1611837> | 16:05 |
| mvo | sergiusens: pfffff ;) | 16:06 |
| mvo | ogra_: the way the kernel.img/initrd.img is extracted will change soon, once that change lands we can no longer use a symlink inside the kernel, it needs to be the actual file, could you please update livecd-rootfs so that the real file is kernel.img/initrd.img and the others are symlinks? | 16:08 |
| ogra_ | mvo, well, i'll ripp all that code out of livecd-rootfs ... but yeah, i'll take it into account for the automated kernel snaps | 16:09 |
| ogra_ | mvo, do we need the versioned filenames at all then ? | 16:09 |
| mvo | ogra_: no, it might just be nice for manual inspections | 16:10 |
| ogra_ | (i remember some requirement about matching versions in the kernel yaml spec) | 16:10 |
| mvo | ogra_: we may need it soon, but I can can manually tweak the snaps if needed, it just needs to be there | 16:10 |
| mvo | ogra_: kernel.yaml got killed | 16:10 |
| ogra_ | ok | 16:10 |
| ogra_ | oh ? | 16:10 |
| ogra_ | when ? | 16:10 |
| ogra_ | today ? | 16:10 |
| ogra_ | :) | 16:10 |
| mvo | ogra_: during the heidelberg sprint, I think you were in the session ;) but maybe not, I'm not sure, its definitely in the notes | 16:11 |
| ogra_ | NO, I WASNT IN ANY KERNEL SESSION, WHEN I ASKED ABOUT IT I WAS TOLD EVERYTHING WAS DONE | 16:11 |
| ogra_ | ARGH | 16:11 |
| * ogra_ rips caps off his kbd | 16:12 | |
| mvo | ogra_: but the kernel version and the version string in snap/meta.yaml much match (eh meta/snap.yaml) | 16:12 |
| mvo | ogra_: uh, no need to shout | 16:12 |
| ogra_ | yeah, sorry | 16:12 |
| * ogra_ hands out earplugs | 16:12 | |
| kyrofa | jdstrand, zyga where is the SRU bug for snap-confine? | 16:12 |
| mvo | ogra_: aha, ok. well, I don't remember the details but I have it in the kernel/gadget.yaml notes, so less work | 16:12 |
| * mvo switches network | 16:12 | |
| kyrofa | Jeez ogra_, take it easy | 16:12 |
| ogra_ | mvo, werll, thats a snapcraft thing, none of my code touches snap.yaml anymore ... it is all snapcraft now | 16:13 |
| jdstrand | kyrofa: https://people.canonical.com/~ubuntu-archive/pending-sru.html | 16:14 |
| jdstrand | kyrofa: oddly, it is listed but with no bugs | 16:14 |
| kyrofa | jdstrand, indeed, I was just looking to subscribe to it so I knew when it made it through | 16:14 |
| jdstrand | kyrofa: I think that is because 1.0.38-0ubuntu0.16.04.4 fixed something and it needed -v | 16:14 |
| stokachu | so im trying to access a binary that I pull in via stage-packages and getting this error in strict mode: | 16:15 |
| ogra_ | mvo, so what exactly needs to match ... snapcraft.yaml's version vs /lib/modules/$name-$version/ ? | 16:15 |
| stokachu | Aug 10 11:54:32 deadpool kernel: [898974.105170] audit: type=1400 audit(1470844472.128:48571): apparmor="DENIED" operation="bind" profile="snap.conjure-up.conjure-up" pid=9807 comm="juju" family="unix" sock_type="stream" protocol=0 requested_mask="bind" denied_mask="bind" addr="@/var/lib/juju/mutex-/store-lock" | 16:15 |
| jdstrand | kyrofa: mvo, I see snap-confine in pending-sru has no bugs. as such it will never get attention from the sru team. I think you needed to have the changelog include pervious versions | 16:15 |
| kyrofa | stokachu, try adding the network-bind plug | 16:15 |
| stokachu | i have network, network-control, network-bind as my plugs | 16:15 |
| stokachu | https://www.irccloud.com/pastebin/0qC1iYnF/ | 16:16 |
| kyrofa | Oh, /var/lib/juju, yeah | 16:16 |
| stokachu | do i need to do plugs for the juju binary? | 16:16 |
| jdstrand | stokachu: https://bugs.launchpad.net/snappy/+bug/1604967 | 16:16 |
| mup | Bug #1604967: Apparmor denies bind to abstract unix sockets such as @/var/lib/juju/mutex-/store-lock <snapd-interface> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1604967> | 16:16 |
| stokachu | ah :) | 16:16 |
| jdstrand | I have a PR that is started but it got pushed behind a couple other things | 16:17 |
| stokachu | jdstrand: ok, i can run in devmode for now | 16:17 |
| jdstrand | yeah, was just going to suggest that | 16:17 |
| stokachu | jdstrand: thanks, ill keep an eye on that bug | 16:17 |
| jdstrand | mvo_: s/changelog/changes/ | 16:17 |
| dragly | Should --devmode allow a snap to access the entire system or is it still sandboxed? | 16:20 |
| mvo_ | jdstrand: sorry, I got disconnected, what did you say earlier? | 16:20 |
| kyrofa | mvo_, you mean this? | 16:24 |
| kyrofa | <jdstrand> kyrofa: mvo, I see snap-confine in pending-sru has no bugs. as such it will never get attention from the sru team. I think you needed to have the changelog include pervious versions | 16:24 |
| jdstrand | s/changelog/changes/ | 16:24 |
| jdstrand | thanks kyrofa :) | 16:24 |
| jdstrand | mvo_: that was it ^ | 16:24 |
| jdstrand | ogra_: with r707: $ PYTHONPATH=./ ./bin/click-review ../click-reviewers-tools-test-packages/ubuntu-core_176.snap | 16:25 |
| jdstrand | ../click-reviewers-tools-test-packages/ubuntu-core_176.snap: pass | 16:25 |
| jdstrand | ogra_: I requested a pull with the store team a moment ago | 16:25 |
| mvo_ | jdstrand: oh, ok. it has a regression anyway so I will have to do a new uplaod soonish | 16:27 |
| jdstrand | mvo_: ok, thanks | 16:27 |
| ahasenack | jdstrand: niemeyer: sorry, I had lunch and irc dropped | 16:27 |
| ahasenack | good to hear something is coming | 16:28 |
| mvo_ | jdstrand: but thanks! | 16:28 |
| ahasenack | and sure, setuid can be used to either drop or gain privileges | 16:28 |
| jdstrand | mvo_: fingers crossed your next upload is the *one* :) | 16:28 |
| ahasenack | I think selinux allows for an "order" of sorts here, i.e., "root" can drop to "squid" in this certain application | 16:28 |
| ahasenack | don't know if apparmor has the same concept | 16:28 |
| jdstrand | ahasenack: we will have something similar | 16:28 |
| mvo_ | jdstrand: yeah, snap-confine was more difficult than expected | 16:29 |
| jdstrand | ahasenack: it doesn't (yet), but with newer snap-confine, we can do it with seccomp | 16:29 |
| ahasenack | jdstrand: ok, so for today, the only option is to patch the app to not drop privileges? | 16:29 |
| jdstrand | ahasenack: yes, or use devmode | 16:29 |
| jdstrand | well, or use an unrelated interface | 16:29 |
| ahasenack | devmode defeats the purpose I think, I'm trying to avoid it really hard | 16:29 |
| ahasenack | patching the app might be hard too, since some go to great lengths to ensure they really dropped the privs | 16:30 |
| jdstrand | ahasenack: devmode is meant only as a temporary thing | 16:30 |
| ahasenack | jdstrand: is there a blueprint or bug tracking this privilege dropping work/intent? | 16:30 |
| jdstrand | we'll allow privilege dropping. at first it will be to a fixed uid, but will expand on that | 16:31 |
| ahasenack | that would be enough to snap this app already | 16:31 |
| jdstrand | there is a trello card, let me check on the bug | 16:31 |
| jdstrand | a bug | 16:31 |
| ahasenack | since it allows configuring the user it runs as | 16:31 |
| ahasenack | (as most do) | 16:31 |
| jdstrand | ahasenack: bug #1581310 is in the same realm (it is for chown). if you are in trello I can add you to the card | 16:33 |
| mup | Bug #1581310: ubuntu-core doesn't allow sed -i (fchown syscall) <snapd-interface> <snapd (Ubuntu):Triaged by jdstrand> <https://launchpad.net/bugs/1581310> | 16:33 |
| ahasenack | jdstrand: does the card get more updates than the bug, or is it enough if I subscribe to the bug? | 16:34 |
| jdstrand | ahasenack: subscribing to the bug would be fine. I will be fixing that bug at the same time as setuid | 16:34 |
| ahasenack | cool, thanks | 16:35 |
| ogra_ | jdstrand, yay, thanks ! | 16:43 |
| dragly | zyga: Built ubuntu-clock-app with snapcraft now, and it works with strict confinement. Seems snapd-confine works as expected. However, the ubuntu-calculator-app does not work after installing with "snap install ubuntu-calculator-app". Trying to build it manually now. | 16:46 |
| dragly | Yes, it works after building it manually. Any reason this should differ from installing it from the repository? | 16:46 |
| mup | PR snapd#1661 closed: docs: private flag doesn't exist on /v2/find (it's select) <Created by robert-ancell> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1661> | 16:48 |
| joc_ | jdstrand: i built a new image from edge as ogra suggested and confirmed it has at least /usr/lib/snapd/snap-confine present, i'm still not getting the behaviour i expected from the interface though | 16:54 |
| ogra_ | joc_, snap list|grep ubuntu-core | 16:54 |
| ogra_ | what revision do yu have | 16:54 |
| joc_ | ogra_: 178 | 16:55 |
| ogra_ | ok, thats the recent build | 16:55 |
| ogra_ | Get:4 http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64 snap-confine amd64 1.0.38-0ubuntu0.16.04.4 [20.4 kB] | 16:56 |
| ogra_ | and thats the version it installed | 16:56 |
| EAbdel | Hey | 17:01 |
| EAbdel | please is there any one connnected here ? | 17:01 |
| jdstrand | joc_: ok. did a file in /etc/udev/rules.d/ get created? | 17:02 |
| joc_ | jdstrand: yes | 17:03 |
| jdstrand | joc_: can you paste the contents? | 17:03 |
| joc_ | http://paste.ubuntu.com/22929166/ | 17:04 |
| jdstrand | joc_: can you paste 'udevadm info /dev/the-thing-you-tried-to-tag'? | 17:07 |
| EAbdel | hi | 17:09 |
| EAbdel | need some help | 17:09 |
| EAbdel | somone here to help me ? | 17:09 |
| joc_ | jdstrand: http://paste.ubuntu.com/22929677/ | 17:09 |
| jdstrand | joc_: ok, so it should have something like: E: TAGS=:systemd:nap_miniterm-joc_open: | 17:10 |
| jdstrand | joc_: but it only has TAGS=:systemd: | 17:11 |
| jdstrand | (obviously I meant 'TAGS=:systemd:snap_miniterm-joc_open:') | 17:11 |
| jdstrand | joc_: because that tag isn't present, snap-confine isn't creating a device cgroup | 17:12 |
| jdstrand | and so the /dev/** line allows everything | 17:12 |
| elopio | sergiusens: josepht: I have a problem here: https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/yaml.py#L136 | 17:13 |
| joc_ | jdstrand: ok, makes sense, to work out why the tag isnt applied then | 17:13 |
| elopio | sergiusens: josepht: why are we getting the remote parts every time? Can we be lazier than that? | 17:14 |
| mup | PR snapd#1666 opened: osutil: change escaping for create-user's sudoers <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1666> | 17:14 |
| sergiusens | elopio in the tests? Because some tests use remote parts and some don't | 17:14 |
| EAbdel | hi | 17:14 |
| jdstrand | joc_: so, ID_VENDOR_ID=10c4 | 17:15 |
| EAbdel | somone workign with snaps ? | 17:15 |
| EAbdel | please | 17:15 |
| elopio | sergiusens: no, every time we load the config we get the remote parts. | 17:15 |
| sergiusens | elopio we clear the xdg home as part of the main test fixture | 17:15 |
| jdstrand | joc_: but you have ATTRS{idVendor}=="0003" | 17:15 |
| sergiusens | elopio let me think into why that is | 17:15 |
| elopio | we should load the remote parts only when they are needed. | 17:15 |
| jdstrand | joc_: did you mix up vendor and product? | 17:15 |
| sergiusens | elopio yes that should be the case | 17:15 |
| sergiusens | elopio which is why I went with the current test solution; this should be fixed once josepht gets the yaml loader stuff refactored | 17:16 |
| jdstrand | joc_: ID_MODEL_ID=0003. I guess that corresponds with the idProduct. anyway, yeah, it looks like things aren't quite right with the rule | 17:16 |
| elopio | sergiusens: I think I can quickly put a property to solve it. /me tries | 17:17 |
| joc_ | jdstrand: oh good spot, i haven't in the plug defintion, sounds like i must have done in the interface code | 17:17 |
| joc_ | that generates the snippet | 17:17 |
| jdstrand | joc_: feel free to adjust the file in /etc/udev/rules.d directly and then do: udevadm control --reload-rules ; udevadm settle ; udevadm trigger ; udevadm settle | 17:17 |
| jdstrand | technically the settles shouldn't be required, but I found they were | 17:18 |
| jdstrand | joc_: after that series of udevadm command you can do the udevadm info /dev/... command and see if it worked | 17:19 |
| jdstrand | joc_: perhaps you knew all this-- if so, you get bonus help :) | 17:19 |
| jdstrand | joc_: once happy, yeah, update the interface accordingly | 17:20 |
| joc_ | jdstrand: looking better, get an E: TAGS=:systemd:snap_miniterm-joc_open: | 17:20 |
| jdstrand | ah good | 17:20 |
| jdstrand | joc_: when you launch the app, the cgroup should be used | 17:21 |
| joc_ | jdstrand: excellent, getting operation not permitted when trying to open other /dev/ttyXXX now | 17:22 |
| jdstrand | perfect-o! | 17:22 |
| joc_ | jdstrand: sorry about that, my fault with the code, but the help on the debugging was much appreciated | 17:23 |
| jdstrand | np | 17:23 |
| jdstrand | joc_: this actually makes me want to investigate something, so that is helpful | 17:24 |
| sergiusens | is anyone having issues with write operations on launchpad? | 17:26 |
| mup | PR snapcraft#657 closed: Add constraints to python2 plugin <Created by SamYaple> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/657> | 17:26 |
| joc_ | jdstrand: something comes to mind for me too | 17:29 |
| joc_ | jdstrand: as this is a usb device i can unplug it | 17:30 |
| joc_ | and now there is no device with tag on so no cgroup and i have access to everything in /dev again | 17:31 |
| jdstrand | joc_: yes, that is precisely what I was talking about investigating | 17:33 |
| jdstrand | joc_: I've added it to the trello card for my part of this interface. it is a bug in snap-confine that will need to be fixed | 17:33 |
| jdstrand | joc_: don't worry about snap-confine. I'll fix it | 17:34 |
| jdstrand | joc_: but I think this shows we should be more defensive with the apparmor rule to limit damage in the event of bugs | 17:35 |
| jdstrand | joc_: is it possible for you to use /dev/tty* instead of /dev/**? | 17:35 |
| jdstrand | joc_: or /dev/ttyUSB*? whatever that can be more fine-granined but not all of /dev/** | 17:36 |
| joc_ | jdstrand: yes i can do and it would limit the damage of falling back to just the apparmor rule | 17:36 |
| jdstrand | it might not be possible. I suspect with the tty subsystem it is though | 17:36 |
| jdstrand | thanks | 17:36 |
| jdstrand | joc_: note, I won't block the interface review on that, but I will mention it in the PR | 17:37 |
| jdstrand | err | 17:37 |
| jdstrand | joc_: by 'that' I meant the snap-confine bug | 17:37 |
| jdstrand | joc_: I also know how to address that bug | 17:37 |
| joc_ | jdstrand: ok, i'll make the changes and propose it soon, thanks | 17:39 |
| jdstrand | joc_: sure thing | 17:39 |
| mup | PR snapcraft#720 opened: Start the fake parts server only in the tests that need it <Created by elopio> <https://github.com/snapcore/snapcraft/pull/720> | 17:47 |
| jdstrand | joc_: you may be wondering why we have this combination of cgroups and apparmor when it would be arguably easier to just update the apparmor profile | 17:53 |
| jdstrand | joc_: the reason is that updating the apparmor profile requires a policy recompile which while not terrible on x86 can be up to a second or more on armhf | 17:54 |
| jdstrand | joc_: so do that on hotplug events is not ideal | 17:55 |
| jdstrand | joc_: so we have cgroups for now. in the future apparmor will grow xattr support such that we will be able to add a rule to the default template that says 'any file with this xattr that matches this security label is allowed'. then we load the policy once and a udev script updates the xattr of the file instead of messing with cgroups | 17:56 |
| jdstrand | joc_: and we can remove the apparmor glob rules and all is nice and clean :) | 17:57 |
| jdstrand | hopefully we'll have that for series 18. we'll see | 17:58 |
| === evnmar_ is now known as evnmar | ||
| mup | PR snapd#1651 closed: osutil: more create-user fixes <Reviewed> <Created by mwhudson> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1651> | 18:01 |
| mup | PR snapd#1665 closed: many: do not require root for `snap prepare-image` <Created by mvo5> <https://github.com/snapcore/snapd/pull/1665> | 18:01 |
| jdstrand | ratliff: you might actually be interested in that last bit with jo c_ ^ | 18:04 |
| jdstrand | ratliff: fyi only | 18:05 |
| ratliff | thanks, jdstrand, interesting indeed | 18:07 |
| ali1234 | why isn't there a snapcraft snap? | 18:07 |
| sergiusens | ali1234 because we cannot build from there yet | 18:09 |
| sergiusens | keyword: yet | 18:09 |
| ali1234 | yes but why? | 18:09 |
| ali1234 | would it work in devmode? | 18:10 |
| ogra_ | it will even work with strict confinement ... just be patient ;) | 18:11 |
| ogra_ | GRR ... | 18:12 |
| ogra_ | https://code.launchpad.net/~ogra/+snap/kernel-test-snap | 18:12 |
| ogra_ | i start hating our arm builders | 18:12 |
| ogra_ | ("starting in 18min" ... since 2h :P ) | 18:12 |
| ali1234 | what is the correct way to change the hostname on an all-snap system? | 18:13 |
| ali1234 | ogra_: i tried to make classic use an overlay, now it won't boot at all | 18:19 |
| kyrofa | ogra_, have you tried the auto-upload from LP from an account with whom the snap was shared yet? | 18:22 |
| mup | PR snapcraft#698 closed: Add option disable-parallel for all plugins <Created by blakerouse> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/698> | 18:44 |
| stokachu | do interfaces get installed automatically? | 19:05 |
| stokachu | fo rexample if there is a juju interface that we would plug into | 19:05 |
| stokachu | juju snap would need to be installed | 19:05 |
| kyrofa | stokachu, that's likely a question for zyga | 19:08 |
| === davmor2 is now known as davmor2_Hols | ||
| josepht | sergiusens: do you mind adding notes from our discussion to the sub-parts bug? https://bugs.launchpad.net/snapcraft/+bug/1606933 | 19:43 |
| mup | Bug #1606933: parser - Make all parts top-level parts <Snapcraft:In Progress by joetalbott> <https://launchpad.net/bugs/1606933> | 19:43 |
| josepht | sergiusens: I would but the reason for the new file idea escapes me :) | 19:45 |
| mup | PR snapcraft#717 closed: fix checker errors to let runtests.sh pass again <Created by cpaelzer> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/717> | 19:47 |
| arges | jdstrand: hey not sure if https://github.com/snapcore/snapd/pull/1602 is on your queue. The CI test failures seem to be random so i can never tell if its in a bad state or not | 20:02 |
| mup | PR snapd#1602: interfaces: add kernel-module interface for module insertion <Created by arges> <https://github.com/snapcore/snapd/pull/1602> | 20:02 |
| jdstrand | arges: I'll give it a once over for the security policy bits and anything else I happen to see, but a core member of the snappy team will perform the merge | 20:08 |
| arges | jdstrand: thanks. | 20:09 |
| jdstrand | arges: as for the test failures-- yeah, that's annoying. not sure what's happening there lately; things were solid for quite a while... | 20:09 |
| jdstrand | arges: I left two small things to adjust, then LGTM. Please ping me when you commit and I'll say as much in the PR | 20:14 |
| arges | jdstrand: ok | 20:15 |
| ali1234 | hmm... the all-snap image stopped working after i rebooted it a couple of times | 20:18 |
| ali1234 | now it doesn't get past uboot | 20:19 |
| tianon | seeing the same boot issues after updating all-snaps on an amd64 VM too (although stuck in grub, not uboot) | 20:28 |
| ali1234 | i didn't attempt to upgrade it | 20:28 |
| ali1234 | although i gather it does so automatically | 20:28 |
| tianon | IIRC it has auto-update turned on by default | 20:28 |
| tianon | yeah | 20:28 |
| ali1234 | however, i was attempting to reboot because i forgot to plug in the network cable | 20:29 |
| jdstrand | ogra_: if you are still around, would you mind sharing your sshfs snap? | 20:29 |
| ali1234 | so i dunno how it could have downloaded the update... | 20:29 |
| tianon | I can reproduce 100% consistently with https://people.canonical.com/~mvo/all-snaps/16/all-snaps-amd64.img.xz by doing "sudo snap refresh" followed by a reboot | 20:29 |
| arges | jdstrand: fwiw. pushed an update with your changes. I rebased again so not sure what the results of the CI tests will be | 20:40 |
| jdstrand | arges: I think the snappy team prefers to not have rebases fwiw, but I'll take a look | 20:50 |
| ali1234 | how do i make snapcraft use a local git repo? | 20:58 |
| mup | PR snapd#1667 opened: many: implement snaptool command <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1667> | 20:59 |
| ali1234 | also what is the best practice when the snapcraft.yaml exists in the same repo as the source code? | 20:59 |
| ali1234 | hmm... desktop-launch went crazy | 21:14 |
| mup | PR snapcraft#677 closed: playing with caching <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/677> | 21:17 |
| kyrofa | arges, jdstrand indeed, you can squash up for the initial PRs if you want to start clean, but merges only once the PR is created | 21:19 |
| camako | ali1234, this should work : | 21:24 |
| camako | source: /path/to/my/repo | 21:24 |
| camako | source-type: git | 21:24 |
| ali1234 | thanks | 21:24 |
| camako | yw | 21:25 |
| camako | jdstrand, ping | 21:27 |
| ali1234 | but what about when the snapcraft.yaml exists within the project it is compiling? | 21:27 |
| tianon | jdstrand: oh man, I've been updating my PR wrong /o\ I'll keep this in mind for future updates, sorry! :x | 21:28 |
| camako | ali1234, "source: ." | 21:32 |
| ali1234 | yeah that specifically fails for me | 21:32 |
| camako | looking at gitter-im in the playpen may help.. that's what it does. | 21:33 |
| ali1234 | it causes desktop-launch to try to create recursive directories, then it crashes when it hits the dir limit | 21:33 |
| ali1234 | i'm trying to reproduce it on amd64 | 21:36 |
| ali1234 | then i'll upload an example to my museum of broken snaps... | 21:36 |
| jdstrand | camako: hi | 21:42 |
| camako | jdstrand, hi.. I was looking at the mesa gl/gles demos in terms of snappy interface requirements | 21:42 |
| camako | I noticed that they use 'sendmsg' which gets a denial | 21:43 |
| camako | further investigation revealed that it's used to talk to the X server | 21:43 |
| camako | which is a legit thing to do | 21:43 |
| camako | but x11 interface doesn't include sendmsg | 21:43 |
| camako | only 'send' I think | 21:44 |
| camako | and then I thought, other apps (non-gl) would use it too | 21:44 |
| jdstrand | camako: seems fine to add. either file a bug with snapd-interface or do a PR against snapd | 21:44 |
| jdstrand | camako: if filing a bug, please add the 'snapd-interface' tag | 21:45 |
| jdstrand | then we'll get that fixed up | 21:45 |
| jdstrand | I suspect it will want 'sendto' as well | 21:45 |
| camako | jdstrand, will do... out of curiosity, how come no other X11 app has encountered this problem? | 21:46 |
| jdstrand | camako: not sure. what architecture are you using? | 21:46 |
| camako | I'm on AMD64 with intel (i965) gpu | 21:46 |
| jdstrand | yeah, that's odd | 21:46 |
| jdstrand | guess your snap made an api call that others don't typically use | 21:46 |
| jdstrand | and that call ended up using sendmsg | 21:47 |
| camako | jdstrand, I traced it to 'glXMakeCurrent' | 21:47 |
| ali1234 | most X11 code doesn't use GL, and most GL code doesn't use X11 features directly... | 21:48 |
| jdstrand | there you go | 21:48 |
| jdstrand | it's interesting how things like this crop up | 21:49 |
| camako | jdstrand, don't we have apparmor protection on ubuntu outside snappy? | 21:49 |
| jdstrand | it's an easy fix so we can get it into the next snapd release without issue | 21:49 |
| jdstrand | camako: apparmor is used in various places, sure (/me notes we are talking about seccomp here) | 21:50 |
| camako | jdstrand, abstractions/X (which allows 'send') is under apparmor, so I was going with that | 21:51 |
| jdstrand | camako: that's a different send | 21:51 |
| camako | so I'm wondering without sendmsg, how is an app like glxgears end up working? | 21:51 |
| jdstrand | camako: in snappy we have both apparmor mediation and seccomp filtering | 21:51 |
| camako | ah ok | 21:51 |
| jdstrand | seccomp is the first line, then apparmor | 21:52 |
| camako | ok I'll file a bug | 21:52 |
| jdstrand | seccomp is way more coarse-grained, but the combination of the two is compelling | 21:52 |
| camako | ack | 21:52 |
| jdstrand | cause we can say, block module loading at the syscall level even if the apparmor policy would allow it | 21:53 |
| jdstrand | (it doesn't, you'd need sys_module so not the best example, but the point is, we use them in combination for a strong sandbox) | 21:53 |
| camako | right | 21:54 |
| jdstrand | the sandbox is mostly apparmor, but the seccomp filtering comes in handy where apparmor doesn't yet implement an lsm hook | 21:54 |
| jdstrand | kernel keyring is a good example. we can also block known problematic or ancient syscalls to reduce the kernel attack surface | 21:54 |
| jdstrand | anyhoo, yes, file a bug and I'll get it fixed | 21:55 |
| camako | jdstrand, I'll file a bug, but I am keen to understand why things are working on the desktop. | 21:55 |
| camako | # the unix socket to use to connect to the display | 21:55 |
| camako | /tmp/.X11-unix/* w, | 21:55 |
| camako | unix (connect, receive, send) | 21:55 |
| camako | ^^ these lines from the X file | 21:56 |
| camako | caught my eye | 21:56 |
| jdstrand | camako: so, on the desktop most X apps shipped as debs aren't confined by apparmor (or seccomp) | 21:56 |
| camako | I'm assuming for non-snappy desktop apps, this is used? | 21:56 |
| camako | ah ok then.. | 21:56 |
| camako | :-) | 21:57 |
| camako | thanks for the explanation | 21:57 |
| jdstrand | camako: when you confine an X app with apparmor, then you need a unix rule from the X abstraction. those use apparmor syntax and are not syscalls | 21:57 |
| camako | I see | 21:57 |
| jdstrand | camako: when you then setup a seccomp filter for the app, then you see the syscalls it uses | 21:57 |
| jdstrand | so on snappy you get both. on non-snappy, neither or possibly just apparmor | 21:58 |
| camako | I was running an app that I compiled... would that have been confined by apparmor? | 21:58 |
| zyga | o/ | 21:58 |
| jdstrand | camako: no | 22:01 |
| ali1234 | hmm... can't reproduce with a simple helloworld snap | 22:09 |
| mup | Bug #1611978 opened: Incomplete x11 interface <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1611978> | 22:13 |
| ali1234 | well that's annoying | 22:33 |
| === King_InuYasha is now known as Son_Goku | ||
| sergiusens | robert_ancell hey, mind updating https://github.com/snapcore/snapcraft/pull/670 ? | 23:18 |
| mup | PR snapcraft#670: Remove .la files generated by autotools <Created by robert-ancell> <https://github.com/snapcore/snapcraft/pull/670> | 23:18 |
| robert_ancell | sergiusens, ok | 23:18 |
| ali1234 | something is very wrong here: http://paste.ubuntu.com/22968449/ | 23:20 |
| sergiusens | ali1234 we had this same problem, well stokachu did and it was related to having a command in the snap calling an internal to the snap binary with the same name and exec doing its thing of infinitely calling upon itself due the the in snap command having a bad shebang | 23:47 |
| ali1234 | t worked fine yesterday :( | 23:47 |
| ali1234 | there are only two things in the snap: desktop-helper and my binary (infodump) | 23:48 |
| ali1234 | desktop-launcher sorry | 23:48 |
| ali1234 | hmm i see... so desktop-launch is running /snap/bin/infodump instead of /snap/infodump/current/bin/infodump | 23:56 |
| ali1234 | which causes the recursion | 23:56 |
| sergiusens | ali1234 yeah, that would do it | 23:56 |
| ali1234 | but why? | 23:57 |
| sergiusens | ali1234 is /snap/infodump/current/bin/infodump a binary? | 23:57 |
| sergiusens | is it +x? | 23:57 |
| sergiusens | if it has a shebang, is it correct? | 23:58 |
| ali1234 | it *should* be a binary | 23:58 |
| ali1234 | hang on i have to build it again to know for sure | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!