| === zyga_ is now known as zyga | ||
| zyga | good morning | 05:49 |
|---|---|---|
| === blr_ is now known as blr | ||
| === JanC is now known as Guest37928 | ||
| === JanC_ is now known as JanC | ||
| morphis | zyga: ping | 08:00 |
| zyga | morphis: hey, good morning | 08:00 |
| morphis | zyga: morning! | 08:00 |
| morphis | zyga: wondering if you tested the bluez interface changes at runtime as I am getting invalid apparmor profiles with those changes | 08:01 |
| zyga | morphis: hmm, no I did not | 08:01 |
| morphis | doesn't seem to like peer=(label=snap.bluez.{bluez,obex}), | 08:01 |
| zyga | morphis: can you pastebin what you're getting? | 08:02 |
| zyga | hmmm | 08:02 |
| zyga | I see, thanks, jdstrand suggested those nad I assumed it would be digested | 08:02 |
| morphis | zyga: https://paste.ubuntu.com/16186420/ | 08:02 |
| zyga | ok, let me look | 08:03 |
| * zyga curses at 2fa | 08:03 | |
| zyga | why does it need to auth me for a f.... pastebin | 08:03 |
| zyga | Plain form not available for deep linking. | 08:04 |
| zyga | morphis: odd, for me it complains at line 241 | 08:08 |
| zyga | AppArmor parser error for test.aa in test.aa at line 241: syntax error, unexpected TOK_ID, expecting TOK_CONDID or TOK_END_OF_RULE | 08:08 |
| zyga | and that is: # for 'udevadm trigger --verbose --dry-run --tag-match=snappy-assign'$ | 08:08 |
| zyga | ?? | 08:08 |
| zyga | I think line numbers are broken | 08:09 |
| zyga | it really complains about signal peer=snap.@{SNAP_NAME}.*,$ | 08:09 |
| * zyga experiments | 08:09 | |
| zyga | morphis: it's clear that something is quite not right | 08:11 |
| zyga | morphis: can we wait till jdstrand or tyler shows up? | 08:11 |
| morphis | sure | 08:14 |
| morphis | zyga: reworking the network-manager interface now | 08:14 |
| slvn | hello ! got some issue with my snap. Running "snap-review mysnap" says "checksums do not match.". I can't upload it to the store because of that. I have tested the "opencv" example and it worked. | 08:15 |
| slvn | I have also tested the command lines "snapcraft snap <DIR>" or "mksquashfs <dir> ..". But it failed also the checksum test. | 08:16 |
| zyga | slvn: we know that, at least on pi2, mksquashfs is not really deterministic | 08:20 |
| zyga | maybe it affects other arches | 08:20 |
| zyga | slvn: for now I'd report a bug and try to investigate | 08:21 |
| slvn | zyga, could you (quickly) double-check with the SDL2 package that it also fail on your side ? I am on amd64, and build for amd64 | 08:24 |
| zyga | slvn: I'm somewhat busy but if you run it 100 times and collect the distribution of the hashes that would make a fantastic bug report | 08:24 |
| zyga | slvn: note, run mksquashfs only | 08:25 |
| slvn | ok why not ... | 08:25 |
| slvn | how can I get the hash ? checksun mysnap.snap ? | 08:25 |
| zyga | slvn: sha512sum | 08:26 |
| * zyga explores how to refactor snapenv | 08:26 | |
| slvn | and you say, I only need to re-do "snapcraft snap" ? | 08:26 |
| zyga | I'd just re-do the squashfs command but snapcraft snap is close enough | 08:27 |
| slvn | zyga, I get something like : http://paste.ubuntu.com/16186526/ | 08:31 |
| zyga | hmm | 08:31 |
| zyga | perhaps snapcraft snap is not enough | 08:31 |
| zyga | as in, it does changes to snap/ files | 08:32 |
| zyga | kyrofa, sergiusens: ^^ | 08:32 |
| slvn | zyga, something like "mksquashfs <dir> <snap> -noappend -comp xz -all-root -no-xattrs" ?? | 08:33 |
| zyga | yes | 08:33 |
| slvn | same randomness .. | 08:36 |
| zyga | slvn: report that as a bug on squashfstools please | 08:36 |
| zyga | definitely worth investigating | 08:36 |
| slvn | ok | 08:37 |
| zyga | slvn: can you also check if it is the same if you use something to turn of paralell compression? | 08:37 |
| slvn | zyga, I was about to test that. But I haven't find the option | 08:37 |
| slvn | op yes -processors | 08:38 |
| slvn | I try | 08:38 |
| zyga | slvn: -processors 1 | 08:38 |
| slvn | also failing :/ | 08:39 |
| slvn | I will do the bug report ! | 08:39 |
| morphis | zyga: I will most likely write the snap label replacement code you wrote for the plug side also for the slot side | 08:40 |
| zyga | sure | 08:41 |
| zyga | morphis: if you figure out why apparmor doesn't accept the file you sent me feel free to fix the shared function too | 08:41 |
| zyga | morphis: and note that for me it also failed on line mid-file | 08:41 |
| zyga | morphis: on all-up-to-date xenial | 08:41 |
| morphis | ok | 08:41 |
| morphis | zyga: https://github.com/ubuntu-core/snappy/pull/1036#discussion_r60144002 is what I am currently looking into | 08:42 |
| morphis | but trying first to rework the rules a bit | 08:43 |
| zyga | morphis: keep this in mind: https://github.com/ubuntu-core/snappy/pull/1036#issuecomment-215841904 | 08:43 |
| zyga | morphis: the 'works on the desktop' aspect | 08:44 |
| morphis | zyga: so how can I test that? | 08:44 |
| zyga | morphis: snap nmcli separately perhaps? | 08:44 |
| morphis | and how do I say that the ubuntu-core snap provides the interface? | 08:44 |
| zyga | morphis: you want to look at snap/implicit.go | 08:45 |
| morphis | ok | 08:45 |
| zyga | morphis: but you'll have to bite the bullet and make it dependant on being on the desktop (say dpkg/info exists) | 08:45 |
| morphis | hm | 08:45 |
| zyga | but don't worry | 08:45 |
| zyga | there's similar code in ubuntu-core-launcher | 08:46 |
| pedronis | zyga: we really need to talk (with mvo etc) about what's the official way to detect desktop vs not | 08:46 |
| pedronis | we need an official helper somewhere for that | 08:46 |
| morphis | zyga: my only fear is this will bringup another lengthy discussion | 08:46 |
| morphis | so I would like to do that after the first PR | 08:46 |
| morphis | or let you guys do it properly | 08:46 |
| zyga | morphis: no worries, I'll help you out | 08:48 |
| morphis | zyga: sure but I want to get a first version merged soon, this is already pending for too long | 08:48 |
| morphis | zyga: also I am getting | 08:52 |
| morphis | peer=(label=snap.network-manager.networkmanager), | 08:52 |
| morphis | in the plug apparmor file | 08:52 |
| morphis | with your method from utils.go, shouldn't that be snap.network-manager.nmcli? | 08:52 |
| zyga | hmm | 08:53 |
| zyga | yes, let's see what I did there | 08:53 |
| zyga | is networkmanager an app name? | 08:55 |
| slvn | zyga, I haven't reported the bug yet because my testcase was passing the checksum test :)... so I found out something: adding a line "stage-packages: [ .. ]" solve the issue ... | 08:57 |
| zyga | slvn: curious | 08:59 |
| slvn | yep, I add a stage-package line in my "real" package, and it worked also. I will report that ... | 08:59 |
| morphis | zyga: it is | 09:00 |
| zyga | morphis: so that is correct, the plug can talk to the slot | 09:00 |
| morphis | ok | 09:00 |
| morphis | zyga: however I am wondering if its ok to include the client app name in the permanent slot apparmor policy, propably not | 09:03 |
| zyga | hmm, why? | 09:03 |
| zyga | client app name in permanent slot? | 09:03 |
| zyga | isn't that what per-connection snippet should do | 09:04 |
| morphis | zyga: https://paste.ubuntu.com/16186665/ | 09:04 |
| zyga | morphis: is nmcli connected to nm? | 09:05 |
| zyga | morphis: it seems to be the same as bluez and bluetoothctl | 09:05 |
| morphis | yes | 09:05 |
| morphis | zyga: see https://github.com/ubuntu-core/snappy/pull/1036#discussion_r60144002 | 09:05 |
| morphis | that is what I had before | 09:05 |
| morphis | but jdstrand said we should use proper snap.* names too | 09:05 |
| morphis | for bluez we didn't do that | 09:06 |
| zyga | wasn't that what my earlier patch (now broken apparently) did? | 09:06 |
| morphis | https://github.com/ubuntu-core/snappy/blob/master/interfaces/builtin/bluez.go#L74 | 09:06 |
| zyga | ah, I see | 09:07 |
| zyga | I'm somewhat confused though | 09:07 |
| zyga | do we need this on both slot and plug ends? | 09:07 |
| zyga | if the slot side permission didn't exist | 09:08 |
| zyga | would the plug-side connection permission suffice? | 09:08 |
| morphis | zyga: not sure too | 09:08 |
| morphis | playing a bit with more generic rules right now | 09:09 |
| slvn | https://bugs.launchpad.net/snapcraft/+bug/1577333 | 09:12 |
| ubottu | Launchpad bug 1577333 in Snapcraft "snap-review failed with "checksums do not match"" [Undecided,New] | 09:12 |
| morphis | zyga: ok, I have a simpler version working now which pretty much looks the same as the bluez one | 09:27 |
| ogra_ | mvo, looks like your latest u-d-f is broken, mind rolling it back (or do we need to update the gadgets ? ... looks more like squashfs-tools to me though) | 09:41 |
| zyga | ogra_: see the bug reported by slvn above | 09:45 |
| zyga | it seems that mksquashfs is the new willy wonka | 09:45 |
| ogra_ | http://people.canonical.com/~ogra/snappy/all-snaps/ubuntu-device-flash is the last working one btw | 09:46 |
| * ogra_ has backups ;) | 09:46 | |
| zyga | the last one standing ;) | 09:46 |
| ogra_ | :) | 09:46 |
| morphis | zyga: https://github.com/ubuntu-core/snappy/pull/1036#issuecomment-216181284 | 09:50 |
| zyga | morphis: thanks | 09:51 |
| morphis | zyga: can you give this a last review round? | 09:51 |
| morphis | niemeyer, jdstrand: ^^ | 09:51 |
| zyga | morphis: in a sec | 09:52 |
| morphis | zyga: btw. should I have AutoConnect() { return true }? | 09:52 |
| zyga | morphis: that won't do much on non-desktop | 09:54 |
| zyga | auto-connect only connects to stuff on the OS snap | 09:54 |
| zyga | (today0 | 09:54 |
| morphis | so you be false? | 09:54 |
| zyga | yeah, leave it as false and add a note | 09:54 |
| morphis | ok | 09:54 |
| morphis | zyga: btw. if you want to test the bluez snap we have prebuilt ones at https://code.launchpad.net/~snappy-hwe-team/+snap/bluez | 09:56 |
| zyga | morphis: oh, that's useful, thank you | 09:56 |
| zyga | morphis: I'll get to testing this shortly, I'm mid-way in another branch | 09:56 |
| morphis | sure, take your time :-) | 09:57 |
| === ogra_` is now known as ogra_ | ||
| zzarr | hello! is there a snappy image for dragonboard 410c yet? | 10:40 |
| ogra_ | zzarr, build one yourself ... | 10:42 |
| ogra_ | http://people.canonical.com/~ogra/snappy/all-snaps/ubuntu-device-flash should be the last working ubuntu-device-flash | 10:42 |
| zzarr | nice, thanks ogra_ | 10:43 |
| ogra_ | http://people.canonical.com/~ogra/snappy/all-snaps/dragonboard/README has the runes you need | 10:43 |
| zzarr | thanks ogra_ | 10:45 |
| ogra_ | (do not use the mvo u-d-f, it is currently broken) | 10:47 |
| zzarr | mvo? | 10:48 |
| ogra_ | the one mentioned in the readme | 10:48 |
| zzarr | okey | 10:48 |
| mvo | ogra_: almost ready again | 10:48 |
| ogra_ | good :) | 10:49 |
| zzarr | I use the one you have ogra_ | 10:49 |
| ogra_ | yeah, thats fine then | 10:49 |
| zzarr | it's done (it was quick) | 10:50 |
| zzarr | 100/100 internet connection ssd and a quad core i7... I don't ever have to wait :) | 10:54 |
| mvo | zzarr, ogra_: new u-d-f is up | 10:54 |
| zzarr | nice | 10:54 |
| zzarr | mvo, what are the benefits with it? | 10:55 |
| zzarr | (over ogra_'s binary?) | 10:55 |
| mvo | zzarr: I don't know what ogra_ binary is doing, sorry so I can't answer | 10:56 |
| zzarr | okey, no problem, maybe ogra_ can tell | 10:56 |
| === pitti` is now known as pitti | ||
| zzarr | thanks for helping me, both of you mvo and ogra_ :D | 10:57 |
| zyga | morphis: I'm adding some inline comments to n-m | 10:57 |
| === pitti is now known as Guest28148 | ||
| morphis | zyga: aye | 10:57 |
| zyga | morphis: quick side question: what's the dichotomy of apparmor doing some checks and dbus.xml doing what looks like the same checks again | 10:58 |
| morphis | zyga: a more fundamental question we could solve with snappy but for now we want to stick to what upstream does + apparmor on top | 10:59 |
| zyga | morphis: I see, thanks | 10:59 |
| === Guest28148 is now known as pitti | ||
| ogra_ | mvo: my binary is simply the one from brefore it broke :) | 11:28 |
| ogra_ | *before | 11:28 |
| mvo | ogra_: heh, clever! | 11:43 |
| kyrofa | Good morning | 12:12 |
| zyga | jdstrand: around? | 12:25 |
| jdstrand | zyga: hey, I am now | 12:29 |
| zyga | jdstrand: hey! :) | 12:29 |
| zyga | jdstrand: I hope you had a good weekend | 12:30 |
| zyga | jdstrand: we found some issues with apparmor and the {app1,app2} label syntax | 12:30 |
| jdstrand | yes, thank you | 12:30 |
| jdstrand | zyga: you too | 12:30 |
| zyga | jdstrand: check the backlog with morphis above for details | 12:30 |
| zyga | jdstrand: other than that there are some commends on the network-manager interface | 12:30 |
| zyga | jdstrand: and otherwise we're looking good :) | 12:30 |
| morphis | zyga: looking at them now .. | 12:30 |
| jdstrand | zyga: can I see the generated policy? | 12:30 |
| zyga | s/commends/comments/ | 12:31 |
| zyga | jdstrand: one sec | 12:31 |
| zyga | jdstrand: https://paste.ubuntu.com/16186420/ | 12:32 |
| zyga | that's the same pastebin as above | 12:32 |
| zyga | I tried it and I also had an error mid-file about signal and a glob there | 12:32 |
| zyga | not sure what to make of it | 12:32 |
| jdstrand | zyga: use peer=(label="snap.bluez.{bluez,obex}") | 12:33 |
| jdstrand | zyga: ie, put it in quotes | 12:34 |
| zyga | ah, so just " " | 12:34 |
| zyga | morphis: ^^ :) | 12:34 |
| jdstrand | yeah | 12:34 |
| zyga | thanks! :D | 12:34 |
| zyga | jdstrand: did you try to compile it? | 12:34 |
| jdstrand | and you can do that for "snap.bluez.*" | 12:34 |
| zyga | I also got an error with signal mid way | 12:34 |
| jdstrand | zyga: yes | 12:34 |
| zyga | ah ok | 12:34 |
| jdstrand | and "snap.bluez.app1" | 12:35 |
| jdstrand | zyga: as for signal, no issues here. are you compiling on an old kernel? | 12:36 |
| zyga | jdstrand: on 4.4.0-21 | 12:36 |
| jdstrand | it works fine here | 12:36 |
| zyga | if no issues let's disergard that, I'll re-check after this is patched | 12:36 |
| zyga | disregard* | 12:37 |
| * zyga cannot type | 12:37 | |
| morphis | jdstrand: when you have some time, could you look at the reworked apparmor policy of the network-manager inteface? | 12:39 |
| morphis | jdstrand: tried to keep the same things as we already have in the bluez interface definition | 12:39 |
| jdstrand | yes | 12:39 |
| morphis | thanks | 12:40 |
| jdstrand | morphis: as for question or client name in permanent slot, no, we should not do that. We could/should do that in connected slot though | 12:44 |
| morphis | jdstrand: ok | 12:44 |
| jdstrand | s/or client/on client/ | 12:44 |
| kyrofa | zyga, `snapcraft snap` on its own will regenerate the meta/ directory. If you want to essentually only have it call mksquashfs you need to use `snapcraft snap <dir>` | 12:44 |
| zyga | kyrofa: ah, thanks | 12:44 |
| kyrofa | zyga, it does that so it picks up on YAML changes like changing the snap name, etc. | 12:45 |
| urm8 | hello! | 12:52 |
| urm8 | Hi people | 12:52 |
| urm8 | where do I get newest info about Snappy, including forum discussions on building and stuff like that? | 12:53 |
| zyga | urm8: hey, right here is one spot, I know that many people also use ask ubuntu | 12:53 |
| zyga | urm8: I'd recommend snappy-app-devel maliling list as well | 12:54 |
| urm8 | that mailing list looks like the one. | 12:54 |
| urm8 | Thanks | 12:54 |
| zyga | urm8: there's also snappy-devel as well | 12:54 |
| urm8 | I wanted to pack OpenFoam, but the learning curve to deb packing seem though, so I thought maybe giving the Snappy way a try! | 12:55 |
| urm8 | brb | 12:55 |
| === pippo is now known as cdio | ||
| kgunn | zyga: thot you'd be off today, but hey...after some discussion late friday with jdstrand, i think i really am stuck | 12:58 |
| kgunn | i've got nil nil returning for everything but aa/seccomp on perm slot | 12:58 |
| zyga | kgunn: hey? why is that? | 12:59 |
| kgunn | but when i try to install my snap, it complains about dbus? | 12:59 |
| kgunn | and i don't even have dbus or any need for it | 12:59 |
| zyga | can you be more specific please? | 12:59 |
| kgunn | yep one sec | 12:59 |
| ogra_ | asac, http://people.canonical.com/~ogra/snappy/all-snaps/canonical-pi2_3.3_all.snap in case you want to help testing :) | 13:01 |
| kgunn | zyga: will get back to you in a minute with some pastebins...first have to clean up an experiment i ran late friday | 13:06 |
| zyga | kgunn: ok, I'm in a metting now, happy to work with you after | 13:07 |
| urm8 | Hi people, is there a begginer guide to snappy too? | 13:16 |
| sborovkov | Hello, which interface should I use to allow shared memory access? (peration="mknod" profile="snap.screenly-client.viewer" name="/dev/shm/WK2SharedMemory.907069164" pid=1006 comm="ld-linux-armhf." requested_mask="c" denied_mask="c" fsuid=0 ouid=0) | 13:18 |
| zyga | sborovkov: ask jdstrand, perhaps none, in that case please file a bug on snappy (on launchpad) | 13:26 |
| sborovkov | zyga: ok, got it | 13:27 |
| sborovkov | jdstrand: Hello, is there an interface to allow shared memory access? | 13:27 |
| zyga | sborovkov: to be clear, there's no specific interface, apps should have *some* shm access today | 13:27 |
| zyga | perhaps the some value needs tweaking | 13:27 |
| jdstrand | sborovkov: looking at your denial you need to adjust your app to use /{dev,run}/shm/snap/@{SNAP_NAME}/@{SNAP_REVISION}/ | 13:28 |
| jdstrand | tbh, I never understood why that directory had revision in the path | 13:28 |
| jdstrand | I mean I sorta understood, but for what people use it for, it isn't needed imho | 13:29 |
| zyga | jdstrand: the revision part is problematic, I think | 13:30 |
| zyga | jdstrand: snaps hardly know that (they do but not really easy) | 13:30 |
| jdstrand | I'm totally fine to remove it | 13:30 |
| sborovkov | jdstrand: ok, understood, now just gotta find where it's used in webkit's code. | 13:30 |
| zyga | jdstrand: if it's not a security issue I'd drop revision for sure | 13:30 |
| jdstrand | zyga: SNAP_REVISION is in the env | 13:30 |
| zyga | jdstrand: yes, I know but hardly anyone patches code to use it | 13:30 |
| jdstrand | sborovkov: you might be interested in this historical bug: bug #1197060 | 13:33 |
| ubottu | bug 1197060 in apparmor-easyprof-ubuntu (Ubuntu) "SDK webview applications should use an app-specific path for shared memory files" [Undecided,Fix released] https://launchpad.net/bugs/1197060 | 13:33 |
| sborovkov | jdstrand: Hmm, looks like this was resolved by using 0xide whatever that is. We are using our own build of webkit unfortunately for now so that won't help I guess. I don't understand if with new security I could still use apparmor to tweak this for my app somehow? Or should I just go the route of tweaking paths it accesses | 13:37 |
| ogra_ | uh, webkit ... why do you get yourself into such a security nightmare ? :) | 13:38 |
| sborovkov | ogra_: We had that part written long time ago to display web pages in QML. It also allows nice things like stopping animations, and some other low level stuff which is nice for performance on RPI. Now Qt moved to web engine but I have no idea if anyone even tried porting it to RPI | 13:41 |
| ogra_ | well, oxide definitely runs on armhf devices ... and is well integrated with qml | 13:42 |
| ogra_ | (and fully security maintained in ubuntu) | 13:42 |
| sborovkov | ogra_: I will look at it, I was not aware about it before even. We are moving from raspbian to snappy currently. And have a beta soon, just need to port everything to new security (well once /dev/vchiq can be accessed with it). But need to get out beta for now :-) | 13:44 |
| === kissiel is now known as kissiel-afk | ||
| jdstrand | sborovkov: is there a bug on /dev/vchiq? if not, can you file it describing what the device is and why you need it? please add the 'snapd-interface' bug tag | 13:56 |
| kgunn | zyga: hmmm....ok i made some progress, interesting stumbling block, i'd mod'd your refresh-bits to build off my fork of ubuntu-core/snappy (kgunnfront/snappy)...that seemed to be an issue | 13:57 |
| kgunn | at any rate.. i can install mir-snap now | 13:57 |
| kgunn | https://pastebin.canonical.com/155618/ | 13:58 |
| kgunn | jdstrand: ^ i've not been so excited in quite a while ;) | 13:58 |
| jdstrand | slvn: is your issue one of bug #1576763 or bug #1555305 ? | 13:59 |
| ubottu | bug 1576763 in click-reviewers-tools (Ubuntu) "pi2 images generate different checksums on repeated runs" [Undecided,New] https://launchpad.net/bugs/1576763 | 13:59 |
| ubottu | bug 1555305 in click-reviewers-tools (Ubuntu) "resquashfs test fails if snap has symlinks" [High,Confirmed] https://launchpad.net/bugs/1555305 | 13:59 |
| zyga | kgunn: hmm | 13:59 |
| zyga | kgunn: you cannot change the package name | 13:59 |
| zyga | kgunn: you have to move your fork of snappy into $GOROOT/src/github.com/ubuntu-core/snappy | 13:59 |
| zyga | kgunn: otherwise it will never ever do anything | 13:59 |
| sborovkov | jdstrand: there is one, it has high priority now | 13:59 |
| jdstrand | slvn: if so, please comment in those bugs with any relevant info. otherwise, please file a new bug and let me know the bug number | 13:59 |
| kgunn | zyga: yep...i just copied over my mod'd files to ubuntu-core dir and it worked | 13:59 |
| kgunn | zyga: tools are getting too smart these days :) | 14:00 |
| jdstrand | sborovkov: what is the bug number? | 14:00 |
| zyga | kgunn: glad to hear you are progressing :) | 14:00 |
| sborovkov | jdstrand: https://bugs.launchpad.net/snappy/+bug/1533265 | 14:00 |
| ubottu | Launchpad bug 1533265 in Snappy "/dev/vchiq is inaccessible for unprivileged user" [High,Confirmed] | 14:00 |
| jdstrand | kgunn: woohoo! :) | 14:01 |
| kgunn | i know minor victory | 14:01 |
| ogra_ | jdstrand: we need the re-defined kernel snaps for thsi bug i fear | 14:02 |
| ogra_ | *this | 14:02 |
| zyga | ogra_: why? | 14:02 |
| ogra_ | because we cant ship any udev roles today | 14:02 |
| ogra_ | *rules | 14:02 |
| zyga | ogra_: you can, via interfaces :) | 14:03 |
| zyga | ogra_: interfaces create udev rules | 14:03 |
| jdstrand | it is more than just udev | 14:03 |
| ogra_ | inside the kernel snap ? | 14:03 |
| ogra_ | where would they end up ? | 14:03 |
| zyga | ogra_: inside /lib/udev/rules.d | 14:03 |
| ogra_ | there is no bind mounting or anything for the location they would need | 14:03 |
| jdstrand | zyga: those rules don't do DAC permissions | 14:03 |
| ogra_ | zyga: that would just be ignored at snap install time | 14:03 |
| jdstrand | zyga: the interface udev rules are only for tagging | 14:03 |
| zyga | ogra_: oh, I didn't knowthat | 14:03 |
| jdstrand | I suspect this is a device that won't be covered by the existing implementation | 14:04 |
| jdstrand | I asked for more information in the bug | 14:04 |
| zyga | jdstrand: hmmm, it depends on what we need to do | 14:04 |
| zyga | jdstrand: how is this different from /dev/ic2-1 | 14:04 |
| zyga | jdstrand: (which worked okay) | 14:04 |
| ogra_ | zyga: like you cant ship the kernel config in /boot/config-$uname today ... | 14:04 |
| zyga | (roughly 2/3 months ago) | 14:04 |
| jdstrand | but I suspect /dev/vchiq is something like all the android specific devices on Touch and simply needs to be granted to all apps somehow. we'll see | 14:04 |
| zyga | jdstrand: AFAIR /dev/vchiq is pi specific but perhaps I just know wrong | 14:05 |
| ogra_ | jdstrand: it is a rpi only device afaik | 14:05 |
| jdstrand | zyga: if you read the bug, the bug says a) they used hw-assign (it is gone) and b) after using hw-assign, the perms are 600 | 14:05 |
| zyga | ogra_: I used interfaces to "hw-assign" /dev/i2c-1 to my snap | 14:05 |
| jdstrand | 'a' would need to be solved with interfaces. 'b' cannot currently | 14:05 |
| ogra_ | zyga: and thats fine | 14:05 |
| sborovkov | jdstrand: I am not sure what it does exactly, but it's needed for h/w decoding on RPI | 14:05 |
| zyga | jdstrand: that's my earlier bug, remember when I said non-background apps should have a chmodded /dev/* | 14:06 |
| zyga | jdstrand: it works if you are a service | 14:06 |
| zyga | jdstrand: (you run as root, the tagging does the rest) | 14:06 |
| * ogra_ still thinks that needs solving on a kernel level first | 14:06 | |
| jdstrand | we can't just chmod stuff | 14:06 |
| zyga | jdstrand: I argued that we should chmod the device to 666 if it's tagged | 14:06 |
| zyga | (in the cgroup) | 14:06 |
| jdstrand | I know you did | 14:06 |
| jdstrand | that isn't the right solution | 14:06 |
| jdstrand | it is too simple | 14:06 |
| ogra_ | why not use udev-acl here ? | 14:06 |
| ogra_ | and ship a udev rule for ti | 14:07 |
| zyga | jdstrand: too simple and thus too open or what? | 14:07 |
| jdstrand | it might be ok for this device, but it might not be for another device | 14:07 |
| ogra_ | *it | 14:07 |
| zyga | jdstrand: if there's no tagging there's no cgroup, no chmod | 14:07 |
| zyga | jdstrand: if there's tagging it is precisely because we want to allow access to the device | 14:07 |
| jdstrand | I know, but just because it is tagged doesn't mean non-root should have access | 14:07 |
| jdstrand | maybe it should. maybe it shouldn't | 14:07 |
| zyga | jdstrand: plus remember that we can always apparmor-away all bits we don't want | 14:07 |
| zyga | jdstrand: I remember the discussion, I know it's still an open question | 14:07 |
| zyga | jdstrand: but it somewhat feels like policykit discussion we had with gustavo a while aog | 14:08 |
| zyga | ago* | 14:08 |
| zyga | jdstrand: when it's granted, it should be just allowed | 14:08 |
| zyga | jdstrand: still, that's my 0.02 | 14:08 |
| jdstrand | and I maintain my objection to the simplistic approach | 14:08 |
| jdstrand | we captured this in that doc a while ago. we can pick it up at another time | 14:09 |
| zyga | jdstrand: given that if we say you cannot open without root, anyone can just ship a service that exposes it | 14:09 |
| zyga | jdstrand: so I'd say it's not security but obfuscation at some level | 14:09 |
| zyga | jdstrand: sounds good | 14:09 |
| jdstrand | only if you assign it to the root service | 14:09 |
| zyga | jdstrand: you assign it to a snap, what the snap author does is not something we control | 14:10 |
| jdstrand | there's a lot of things to consider | 14:10 |
| zyga | jdstrand: if it is assigned to a non-root cli tool then it's still under our control via the cgroup | 14:10 |
| jdstrand | I understand what you are saying | 14:10 |
| jdstrand | but the security policy is something that uses DAC as well as our sandbox | 14:11 |
| zyga | sorry, I'm not trying to convince you, I'm just arguing because I think there's no extra security in this mode and I'm hoping you will show me I'm wrong :) | 14:11 |
| jdstrand | we need to be extremely careful | 14:11 |
| zyga | agreed | 14:11 |
| jdstrand | especially when moving forward with multi-user, Ubuntu Personal and if we ever do opt-in per-app UIDs | 14:12 |
| jdstrand | there is a lot to consider | 14:12 |
| jdstrand | anyway, I can't consider all of this right this second-- I have meetings to attend to and PRs to review | 14:12 |
| jdstrand | :) | 14:12 |
| zyga | sure, no worries | 14:12 |
| sborovkov | Alright guys, I am gonna come back in few days and ask you again about this. If there is no solution in sight I can use custom kernel snap/whatever I guess - though it would be very nice if it's possible to upgrade in the future to stock ones without reflashing SD cards | 14:18 |
| === Aria22 is now known as Aria22|away | ||
| dragly | Has there been any updates on accessing OpenGL in snaps? Last week I forgot to issue a bug report after I last talked on this channel about the trouble I had with Snapcraft+Qt+OpenGL on Nvidia hardware. | 14:32 |
| dragly | I tried the ubuntu-clock-app example now, and I still get the "Unrecognized OpenGL version" error when running it after installation. Should I file a bug report or is this already fixed in a newer version of snapcraft? I'm using 2.8.4. | 14:35 |
| zyga | dragly: there were no changes on the desktop that are released yet, we are working on the first SRU now | 14:37 |
| zyga | dragly: though I'm not sure if that particular bug is fixed there already (it might be) | 14:37 |
| dragly | anything in "proposed", or do I need to clone the repo to see if it has been fixed? | 14:39 |
| kgunn | here's a bug link to track that | 14:42 |
| kgunn | https://bugs.launchpad.net/snappy/+bug/1574851 | 14:42 |
| ubottu | Launchpad bug 1574851 in Snappy "libgl not found on nvidia machines (so far)" [Critical,Triaged] | 14:42 |
| sergiusens | jdstrand hello! Can I inject raw apparmor to test something out somehow? hint, relate to /dev/shm | 14:46 |
| zyga | sergiusens: maybe | 14:46 |
| zyga | sergiusens: I can help you out | 14:46 |
| zyga | sergiusens: do the connection and all the other stuff you want | 14:46 |
| zyga | sergiusens: then edit /var/lib/snapd/apparmor/profiles/* | 14:47 |
| sergiusens | zyga k, thanks | 14:47 |
| zyga | sergiusens: then run apparmor_parser -r /path/to/that/file | 14:47 |
| zyga | sergiusens: that should do the trick | 14:47 |
| zyga | sergiusens: just keep in mind that various operations will erase that change | 14:47 |
| sergiusens | zyga do I need to run anything after editing? | 14:48 |
| kgunn | ok, i'm stuck with https://pastebin.canonical.com/155621/ | 14:49 |
| zyga | sergiusens: apparmor_parser -r | 14:49 |
| zyga | sergiusens: on the file | 14:49 |
| zyga | sergiusens: to actually load it | 14:49 |
| kgunn | basically says it can't find mir-server when it's clearly part of the smae | 14:49 |
| kgunn | *snap | 14:49 |
| sergiusens | zyga says already loaded, how do I unload? | 14:50 |
| kgunn | and this used to "just work" | 14:50 |
| zyga | sergiusens: -r reloads it | 14:50 |
| zyga | technically -r is replace | 14:51 |
| zyga | so just -r :) | 14:51 |
| dragly | kgunn: Thanks! I'll subscribe to the bug. | 14:53 |
| kgunn | sergiusens: mvo i feel like this might be more in your wheelhouse, my mir-server.snap used to work & unchanged, i add mir i/f to builtin, mir snap installs...i see mir-server:mir in plug list | 14:55 |
| kgunn | but then it fails with https://pastebin.canonical.com/155621/ | 14:55 |
| === Aria22|away is now known as Aria | ||
| === Aria is now known as Aria22 | ||
| kgunn | saying it can't find mir-server which i can very well navigate to the current snap and see it there | 14:56 |
| kgunn | did some pathing assumptions possibly change? | 14:56 |
| asac | ogra_: whats that image? | 14:57 |
| morphis | jdstrand: what about leaving the discussion to make that network-manager interface working on desktop up to another PR? | 14:58 |
| ogra_ | asac, THATS A GADGET WITH WROKING SERIAL | 14:58 |
| asac | ogra_: ah... well, i cant use udf still :/ | 14:58 |
| ogra_ | EEEK | 14:58 |
| asac | need full blown images | 14:58 |
| asac | hehe | 14:58 |
| * ogra_ whacks his caps key | 14:58 | |
| jdstrand | morphis: I'm fine with that so long as there is a note in the PR about it (or even in the policy) | 14:58 |
| * jdstrand was just going be what niemeyer asked for | 14:58 | |
| jdstrand | s/be/by/ | 14:59 |
| kgunn | so, using $SNAP_APP_PATH in my files, is that correct? or did it change to something like $SNAP | 14:59 |
| morphis | jdstrand: yeah, commented for him on the PR about that | 14:59 |
| jdstrand | kgunn: those changed | 14:59 |
| morphis | niemeyer: would that be ok for you? | 14:59 |
| jdstrand | kgunn: SNAP is install, SNAP_DATA is /var, SNAP_USER_DATA is /home | 14:59 |
| kgunn | jdstrand: thanks | 14:59 |
| jdstrand | kgunn: I often find myself using 'hello-world.env|grep SNAP' :) | 15:00 |
| kgunn | jdstrand: i presume that's on a wiki somewhere and i just got lulled into previous glory/success :) | 15:00 |
| sergiusens | kgunn its just $SNAP | 15:00 |
| kgunn | thanks guys | 15:00 |
| jdstrand | kgunn: I'm not sure of that. the docs are in the process of being updated. dpm may have more details | 15:00 |
| === kissiel-afk is now known as kissiel | ||
| dpm | jdstrand, kgunn, I'm missing some context on what you're trying to do, but that might help in the meantime: http://askubuntu.com/questions/762354/where-can-ubuntu-snaps-write-data/762405#762405 | 15:04 |
| kgunn | dpm: thanks...was just sharing i was lost :) | 15:04 |
| kgunn | i was still using snap_app_path | 15:04 |
| kgunn | didn't realize it changed | 15:05 |
| jdstrand | dpm: we were talking about the status of the docs wrt 16 changes (of which env vars is one part) | 15:05 |
| asac | kgunn: hello-world.env is your friend :) | 15:05 |
| asac | oh that was already suggested | 15:06 |
| asac | hehe | 15:06 |
| kgunn | asac: that's ok, it helps me to be told more than once :-P | 15:07 |
| === chihchunl is now known as chihchun | ||
| asac | lol | 15:10 |
| qengho | kgunn: I wish the Lint tool warned about using deprecated environment variables. | 15:11 |
| asac | kgunn: also hello-world.sh is neat... you end up in a shell inside the app sandbox, so you get a live feel what it means to live in a box :) | 15:11 |
| * asac hopes kgunn learned at least something on top now :) | 15:11 | |
| mvo | kgunn: sorry, was in a meeting. I think the error you see is fixed in master but not yet in the distro, we want to sru this RSN but it is not done yet | 15:18 |
| didrocks1 | ogra_: stupid questions, but where are the fresh vm images for ubuntu core series 16? | 15:19 |
| === cprov_ is now known as cprov | ||
| === dragly_ is now known as dragly | ||
| === clemensv__ is now known as clemensv | ||
| === davidcalle_ is now known as davidcalle | ||
| === Trevinho_ is now known as Trevinho | ||
| sergiusens | jdstrand hey, I wrote an email to the list, mostly intended for you; maybe I am just too ignorant on many things I mention but wanted to get the ball rolling | 15:29 |
| sergiusens | kgunn I've been adding an app to my apps called "shell" with the same plugs as the ones I want to test | 15:30 |
| didrocks1 | mvo: hey, do we have any equivalent of snappy list -u/-v ? | 15:32 |
| mvo | didrocks1: not yet, but please file a bug and we prioritize it | 15:33 |
| === didrocks1 is now known as didrocks | ||
| didrocks | mvo: ok, I think it's the same for rollback and such, isn't it? (I remember there was a set-versions or whatsoever) | 15:34 |
| mvo | didrocks: yes | 15:35 |
| didrocks | ricmm: that's going to make our script about rollback for FTF harder ^ :p | 15:36 |
| didrocks | mvo: bug #1577439 and bug #1577441 (trying to point the next important show we have in it, but I know the timeline is short) | 15:39 |
| ubottu | bug 1577439 in Snappy "No more -u/-v options for "list"" [Undecided,New] https://launchpad.net/bugs/1577439 | 15:39 |
| ubottu | bug 1577441 in Snappy "No way to rollback a snap since the move to snap command" [Undecided,New] https://launchpad.net/bugs/1577441 | 15:39 |
| === kissiel is now known as kissiel-afk | ||
| slvn | jdstrand, the two bugs are https://bugs.launchpad.net/snapcraft/+bug/1575582 and https://bugs.launchpad.net/snapcraft/+bug/1577333 | 15:47 |
| ubottu | Launchpad bug 1575582 in Snapcraft "Snap package, using SDL2, needs access to libGL.so and DRI dependencies" [Undecided,New] | 15:47 |
| ubottu | Launchpad bug 1577333 in Snapcraft "snap-review failed with "checksums do not match"" [Undecided,New] | 15:47 |
| === pitti` is now known as pitti | ||
| === pitti is now known as Guest25655 | ||
| === Guest25655 is now known as pitti | ||
| ogra_ | didrocks, onyl kvm currently (with the normal amd64 image) for vbox you would have to convert yourself ... | 15:54 |
| didrocks | ogra_: do you have any link? | 15:58 |
| didrocks | I looked on cdimage, but only find the preinstalled file system | 15:58 |
| didrocks | no .img | 15:58 |
| === attente_ is now known as attente | ||
| ogra_ | didrocks, nothing beyond mvo's all-snaps dir, we still have no official 16.04 snappy alpha yet | 16:15 |
| didrocks | ogra_: ok, that confirms it! Thanks :) | 16:15 |
| zyga | re | 16:16 |
| * zyga pushed a nice refactor branch https://github.com/ubuntu-core/snappy/pull/1114 | 17:27 | |
| zyga | morphis: I'm done with my current track, I can now look at dbus and quoting what's required | 17:32 |
| zyga | morphis: anything else I can help you with? | 17:33 |
| kyrofa | tyhicks, jdstrand https://code.launchpad.net/~kyrofa/ubuntu-core-launcher/create_user_common_data/+merge/293555 is ready for a look when you're able | 17:44 |
| zyga | kyrofa: some of the error messages confuse allocating memory for filesystem operation failures | 17:50 |
| zyga | confuse as in the error message might be confusing | 17:50 |
| kyrofa | zyga, well remember it results in perror | 17:52 |
| zyga | +char *common_user_data = calloc(common_user_length, 1); | 17:52 |
| zyga | +if (common_user_data == NULL) { | 17:52 |
| zyga | +die("failed to create user common data directory"); | 17:52 |
| zyga | + } | 17:53 |
| zyga | that's clearly confusing IMHO | 17:53 |
| zyga | that's failed to allocate memory, not create anything | 17:53 |
| kyrofa | zyga, the error message will actually say "failed to create user common data directory: out of memory" (or something similar) | 17:53 |
| zyga | hmmm | 17:53 |
| zyga | I see | 17:53 |
| kyrofa | zyga, I didn't want the message to say "unable to allocate memory: out of memory" :P | 17:53 |
| ogra_ | needs to be prefixed with "success:" | 17:54 |
| kyrofa | Hahaha | 17:54 |
| * ogra_ sighs ... so it seems jdstrand made the german news with the ubuntu-core-launcher fix ... | 17:58 | |
| ogra_ | top story at heise.de today ... "another insecurity in snap packages" | 17:58 |
| jdstrand | the joys of open source :) | 17:58 |
| ogra_ | i wish i knew why they dislike us so much recently ... | 17:59 |
| jdstrand | hopefully they reported that it was discovered internally and fixed within a day of discovery | 17:59 |
| ogra_ | nope | 17:59 |
| ogra_ | wow, google translate makes it nearly unreadable ... | 18:01 |
| ogra_ | https://translate.google.com/translate?sl=de&tl=en&js=y&prev=_t&hl=de&ie=UTF-8&u=http%3A%2F%2Fwww.heise.de%2Fnewsticker%2Fmeldung%2FErnste-Sicherheitsluecke-in-Ubuntus-neuem-Paketformat-Snap-geschlossen-3195532.html&edit-text= | 18:02 |
| jdstrand | heh | 18:04 |
| jdstrand | it was fairly even until the end. then there was an axe to gring | 18:04 |
| jdstrand | grind | 18:04 |
| ogra_ | Upon connection of mount points a clerical error resulted in the source code means that the launcher was placed with a correspondingly adapted package name to execute arbitrary code | 18:05 |
| ogra_ | rrright | 18:05 |
| jdstrand | well, I said even, not accurate :) | 18:07 |
| ogra_ | heh | 18:07 |
| jdstrand | they were pretty close | 18:07 |
| ogra_ | yeah, the german sentence is fine there ... | 18:08 |
| sergiusens | jdstrand ok so I created #1577514 | 18:35 |
| * sergiusens should probably reply to the ML as well | 18:36 | |
| === Aria22 is now known as Aria22|away | ||
| === Aria22|away is now known as Aria | ||
| === Aria is now known as Aria22 | ||
| === Aria22 is now known as Aria | ||
| === Aria is now known as Aria22 | ||
| sergiusens | jdstrand ok just to add to the bucket list I've expanded https://bugs.launchpad.net/snappy/+bugs?field.tag=snapd-interface by 4 | 18:57 |
| * zyga soft-EODs | 19:11 | |
| jdstrand | sergiusens: thanks | 19:36 |
| jdstrand | sergiusens: two of those are already fixed in trunk | 19:39 |
| sergiusens | jdstrand sounds good; just wanted to be torough | 19:40 |
| jdstrand | np | 19:40 |
| === Aria22 is now known as Aria | ||
| === Aria is now known as Aria22 | ||
| === peebles_ is now known as peebles | ||
| === mjl_ is now known as mjl | ||
| === kalikiana_ is now known as kalikiana | ||
| === FourDollars_ is now known as FourDollars | ||
| === rsalveti_ is now known as rsalveti | ||
| kgunn | jdstrand: curious one, so i'm getting this denial https://pastebin.canonical.com/155642/ but i have "/run/udev/data/* r," in my slotAA | 20:34 |
| sergiusens | kgunn you might be hit by that snapd bug where you need to remove a snap before installing it again | 20:41 |
| kgunn | sergiusens: i am uninstalling my snap in between | 20:41 |
| kgunn | snap remove mir-server | 20:41 |
| kgunn | i installed with --devmode and it actually launched | 20:42 |
| kgunn | so now just trying to go through the aa/seccomp dance | 20:42 |
| === blr_ is now known as blr | ||
| palerider | well, this looks popular... | 20:50 |
| === thibautr_ is now known as thibautr | ||
| sergiusens | kgunn I don't know how to answer your problem except rinse and repeat | 20:53 |
| kgunn | right, sergiusens, i just thot that specifically having "/run/udev/data/* r," in my slotAA would have taken care of the denials that appeared... | 20:54 |
| kgunn | also i had that in my aa from the beginning | 20:55 |
| kgunn | so wasn't like i added it | 20:55 |
| kgunn | to suppress those | 20:55 |
| === Aria22 is now known as Aria22|away | ||
| === Aria22|away is now known as Aria | ||
| === Aria is now known as Aria22 | ||
| jdstrand | kgunn: that should be allowed by that rule. perhaps the slot didn't connect (ie, the policy isn't in the profile in /var/lib/snapd/apparmor/profiles/...) | 21:59 |
| kgunn | jdstrand: so i just grepped it | 22:02 |
| kgunn | /var/lib/snapd/apparmor/profiles/snap.mir-server.mir-server:246: # /run/udev/data/* r, | 22:02 |
| kgunn | i presume the # is not a good sign | 22:02 |
| jdstrand | kgunn: no. there is a comment about it in the default policy. looks like your slot side didn't connect | 22:03 |
| jdstrand | for your slot side udev apparmor rule | 22:03 |
| jdstrand | (ie, don't be confused be the comment-- your rules 'simply' didn't connect | 22:04 |
| jdstrand | ) | 22:04 |
| kgunn | jdstrand: so what should i look at now? | 22:06 |
| jdstrand | kgunn: is the slot side configured to auto-connect? | 22:08 |
| jdstrand | I thihnk the bluez interface was set to autoconnect | 22:08 |
| jdstrand | let me look | 22:08 |
| kgunn | jdstrand: no i'm not autoconnect | 22:08 |
| jdstrand | otherwise, you could snap remove mit and then install | 22:08 |
| kgunn | (i think) | 22:08 |
| jdstrand | no, bluez isn't | 22:11 |
| kgunn | jdstrand: but, just thinking about it... should mir be autoconnect? | 22:12 |
| jdstrand | well, I'm not sure what the design is supposed to be here | 22:12 |
| jdstrand | I mean, to me it would make sense that the permanent slot policy would autoconnect | 22:13 |
| jdstrand | since it is, well, permanent | 22:13 |
| jdstrand | kgunn: are you still using the trick I gave about putting it in the slot connection portion of the code or is it actually in the slot permanent part? | 22:14 |
| jdstrand | kgunn: regardless, to unblock yourself, you can look at built/opengl.go and set autoConnect: true in your NewMirInterface() which would hopefully unblock you until zyga is back | 22:15 |
| kgunn | jdstrand: right, so i'm actually permanent slot atm | 22:17 |
| jdstrand | kgunn: ok, that's good (in that that is what it should be) | 22:17 |
| kgunn | exactly | 22:17 |
| jdstrand | try playing with autoConnect or moving it to connected slot and doing a manual connect to unblock yourself for the time being | 22:18 |
| kgunn | ok np | 22:18 |
| jdstrand | but we need zyga again | 22:18 |
| kgunn | i mean i can run it with --devmode, so i'm really just wanting to work through doing it the "right way" | 22:18 |
| kgunn | thanks again :) | 22:18 |
| * jdstrand nods | 22:19 | |
| jdstrand | np | 22:19 |
| === Aria22 is now known as Aria22|away | ||
| === devil is now known as Guest7079 | ||
| === asac` is now known as asac | ||
| === Aria22|away is now known as Aria | ||
| example6 | Hello everyone. I'm trying to make a _very_ basic snap consisting of nothing but a few shell scripts. I'm using just the 'copy' plugin to put everything in place, but it doesn't seem to be creating a .snap file OR moving any of the relevant files into snap/ | 23:51 |
| === Aria is now known as Aria22 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!