[00:21] PR snapd#2664 closed: cmd: move seccomp cleanup function to seccomp-support [00:52] PR snapd#2661 closed: tests: skip on untrusted keys === chihchun_afk is now known as chihchun [01:44] I just noticed something interresting. I build an ubuntu-core image with a custom kernel, and when I load the system, it boots up and I can login, but when I look at /lib/modules/`uname -r` there is no directory. Is this something new? [01:45] PR snapcraft#1059 opened: pluginhandler: support more complex stage-packages [01:46] nm, I think I figured it out. [01:47] just to verify in the assertion file, model and gadget are core now, or is it still pc? [04:19] Bug #1643292 changed: /snap/bin/hello - fails to execute with apparmor error. [05:09] PR snapd#2666 opened: Add ability to set system time zone to timeserver_control interface [08:15] PR snapd#2637 closed: tests: increase retries for service up [08:47] PR snapd#2591 closed: wrappers: add DBusActivatable to the allowed values for desktop files [09:08] wililupy_: Hi! I have the same issue with latest core (893), how did you fix it? [09:09] (issue being no /lib/modules nor /lib/firmware) [09:15] PR snapd#2667 opened: tests: ensure systemd override directory is available before using it === faenil is now known as faenil_ [09:39] ogra_: just tried to build the core snap from lp:core-snap, but things are failing with https://paste.ubuntu.com/23832507/ [09:39] ah my fault [09:39] should run it as root [09:39] i'ÄD guess some package is missing [09:40] oh and that, yeah :) [09:53] ogra_: btw. is there any testing for the core snap? [09:53] or does that have to go into snapd? [09:54] theer are regular image tests, yes ... for releasing something into beta/candidate as well as for releasing into stable [09:54] there are zero tests for edge since that is developer playground and allowed to break [09:55] ogra_: so where would I add a test for the configure hook I am adding now into lp:core-snap [09:55] (i'm personally running edge on all boards here though, they auto-update and i usually nothice if they dont boot ... so there is some minimal recofnition of serious breakage) [09:55] morphis_, you apply a patch to fgimenez i guess ;) [09:55] hah [09:56] (the automated spread tests only run for amd64 currently though) [09:57] hm [09:57] fgimenez: ping [09:57] hey morphis_ :) about the above question you can propose the tests to snapd itself and restrict by system [09:58] sounds good [09:58] fgimenez: but that would require me to get a new core snap into edge first, right? [09:59] ogra_, fgimenez: https://code.launchpad.net/~morphis/core-snap/add-configure-hook-sshd-service/+merge/315203 [10:00] morphis_, well, you could use the external backend and run against a prebuilt image, that's how we are testing the board images now [10:00] ah [10:00] good idea [10:00] morphis_, thats definitely not enough ... you need to add tests if there is a local login [10:01] morphis_, here are the details https://github.com/snapcore/snapd/blob/master/tests/external-backend.md [10:01] else any admin can accidentially completely lock himself out [10:01] ogra_: sure, that is why its set as wip [10:02] morphis_, i'd also use start/stop instead of restart ... but thats just a matter of taste [10:02] two commands instead of a single? [10:02] no [10:02] start for enabled ... stop for disabled [10:03] PR snapd#2668 opened: interfaces: abbreviate ConnRef construction [10:03] but as a i said, matter of taste restart will indeed work fine [10:04] (it is just that you trigger two actions with it instead of the one you actually want) [10:07] ogra_: you're ok with the name? [10:08] was wondering if I should use service.ssh or service.sshd [10:08] both are the same for systemd [10:09] yeah, i'm fine with either, make your pick [10:09] PR snapd#2665 closed: cmd: more build system cleanups and a small fix [10:09] probably sshd for consistency ... after all you disable the daemon not the client [10:11] yeah, but that is why it has the service. prefix [10:11] let me leave service.ssh [10:11] I guess niemeyer and mvo will have a opinion too :-) [10:11] ogra_: what would be the best way to check for a local login? [10:12] hmm [10:12] passwd -S maybe [10:12] the most minimal would be to check for non-zero size of /var/lib/extrausers/passwd [10:13] passwd -S will only show the current user [10:13] which in case of a config option will be root i guess [10:13] something like [10:13] test `passwd -S simon | awk '{print $2}'` = P [10:14] and how do you know "simon" ? [10:14] and then looping through the extrausers db and checking each user [10:14] if one found with passwd then we're ok [10:14] + check if he is sudo or not [10:15] ogra@localhost:~$ test -e /etc/sudoers.d/create-user-* && echo foo [10:15] foo [10:16] that is probably sufficient for finding out there is an admin user [10:16] (console-conf creates that file) [10:16] why that? [10:16] ah [10:16] the last bit of the filename is the login [10:16] but that still doesn't give us if that user has a password set [10:16] right, then check for that [10:17] ah [10:17] should be a cheap way to get the login [10:17] however in our case that doesn't work :-) [10:17] as we have a system-user assertion creating a user admin [10:17] and there could be other user assertions creating different users [10:17] and that doesnt enable sudo ? [10:18] all you want to make sure is that there is a sudo user with a password [10:18] and /etc/sudoers.d/ is the only way to create one, /etc/sudoers is readonly [10:19] the other question is, this is policy, do we really want to encode this in the option? in our case a management snap will take care about the whole system and will also have access to the extrausers database [10:19] even your system-user assertion needs to create a file there if there is a sudo capable user [10:19] hmm [10:19] so it may want to enforce that there is not a user at all [10:20] but just the management snap provide a nice UI to manage everything [10:20] tricky [10:20] it is [10:20] and also perhaps something that requires wider discussion via the ML [10:21] I tend to say this is just meant to turn sshd off and the caller needs to know about the consequences [10:21] i personally wouldnt allow turning off sshd through a manually toggleable option if there is no way to get in anymore ... [10:21] probably there is another way to inject that during image creation [10:22] i belive there will be more images like this where you actually dont want a user to exist ... but at the same time it should never be possible to lock yourself out if one exists [10:23] probably the answer is to not make the option runtime switchable at all [10:23] so it can only be triggered by assertion or some such [10:24] maybe [10:24] ogra_: let me get a first working version and then we can discuss this further [10:25] +1 [10:31] PR snapd#2669 opened: asserts: don't use 'context' for the path of attributes, want to reuse the concept for something else [10:32] PR snapd#2670 opened: tests: use higher version number during tests === faenil_ is now known as faenil [11:19] PR snapd#2667 closed: tests: ensure systemd override directory is available before using it [11:29] PR snapd#2668 closed: interfaces: abbreviate ConnRef construction [11:38] fgimenez: ok, I've build my own core snap now and use it to generate an image with ubuntu-image, do I have to set anything specific as snapd doesn't accept it or do I have to rebuild snapd in a special way? === faenil is now known as faenil_ [11:58] ogra_: how are you testing locally build core snaps? [11:58] i boot the image ... install some snaps that use different interfaces (typically htop) [11:59] and usually i leave the image running and watch it update itself daily (since i most of the time look at edge) [12:03] morphis_, i don't think so, you can execute your tests following https://github.com/snapcore/snapd/blob/master/tests/external-backend.md, you could filter by your own test, something like 'spread -v external:ubuntu-core-16-64:tests/main/my-test' [12:04] morphis_, the external backend doesn't make any assumption about what snapd is running, it just tries to connect and execute the given tests [12:08] ogra_, fgimenez: https://paste.ubuntu.com/23833054/ is what I am running into after building an image with $ ubuntu-image --extra-snaps core_16.04.1_amd64.snap -o pc.img pc.model [12:09] so wondering if there is any trick or if snapd should accept my core snap as is [12:10] morphis_, and your model assertion is properly signed with a valid key ? [12:10] ogra_: sure, with my developer key [12:10] PR snapd#2670 closed: tests: use higher version number during tests [12:11] do you see any other errors during boot ? like the firstboot setup job failing or some such ? [12:11] looks really like the initial device setup didnt run [12:11] also, does snap list work at all ? [12:12] it does but lists nothing [12:12] ogra_: none of the snaps from the seed are imported [12:12] PR snapd#2669 closed: asserts: don't use 'context' for the path of attributes, want to reuse the concept for something else [12:13] trying to get a few more details [12:13] yeah, that smells like the device initialization hasnt run ... [12:13] ogra_: but yeah, I passed console-con [12:13] yeah, thats unrelated [12:14] do you have an existing /var/lib/snapd/seed/seed.yaml and the correct content ? [12:15] ah seems to be my fault [12:15] Jan 20 12:13:27 localhost /usr/lib/snapd/snapd[1082]: task.go:303: DEBUG: 2017-01-20T12:13:27Z ERROR rm: cannot remove '/etc/ssh/sshd_not_to_be_run': No such file or directory [12:15] that fails the the installation of the core snap [12:16] just add a "|| true" to the end of the line as a quick hack [12:16] hm, it's not possible to build classic snaps in lxd due to it needing core installed? [12:16] related to bug 1650946 which changed the error message [12:16] Bug #1650946: unhelpful error when building a classic snap: classic confinement requires the core_dynamic_linker to be set [12:16] oh, sergiusens dropped [12:17] your question probably scared him :) [12:19] there ... he's back :) [12:19] PR snapd#2671 opened: add --classic support to try and revert, and make missing these things a little harder [12:37] still having issues getting snapd started and not sure what the culprit is [12:37] https://www.irccloud.com/pastebin/JTrFROJh/ [12:39] PR snapd#2672 opened: cmd: ensure that all .c files have a -test.c file [12:43] mup: is that related to my issue? [12:43] oh4: I really wish I understood what you're trying to do. [12:44] sergiusens: is there a plan to allow building classic snaps inside cleanbuld lxd? [12:44] sergiusens: the error message is now nicer, but... :) [12:45] mup: I am trying to install 'sudo snap install canonical-livepatch' but it requires snapd to be up and running. If I run that command, I get: 'error: cannot communicate with server: Post http://localhost/v2/snaps/canonical-livepatch: dial unix /run/snapd.socket: connect: connection refused' [12:45] oh4: Unknown commands are unknown. [12:45] mup: so then I checked snapd and it isn't running and when I try to start it, I get the error above [12:45] oh4: Can't grasp that. [12:47] oh4, what's the status of snapd.service ? [12:49] oh4: mup is a bot, ignore it. [12:50] popey, I discussed on a solution, just need to work on it, it is top two on my list [12:51] popey: oh...lol [12:51] https://www.irccloud.com/pastebin/ecaBvAIR/ [12:51] popey: ^ [12:52] sergiusens: awesome, thanks. [12:54] seb128: I meant you...sorry ^ [12:55] oh4: is that on ubuntu 16.04? [12:57] yep [12:57] oh4, not snapd.refresh.service, snapd.service [12:57] the refresh is another job [12:59] oops..I meant this, seb128 [12:59] https://www.irccloud.com/pastebin/6K03T5Rn/ [13:03] jdstrand: filed this, but not sure if it's snappy or apparmor.. bug 1658086 [13:03] Bug #1658086: profile has merged rule with conflicting x modifiers [13:03] oh4, this is a plain local ubuntu desktop or server install ? [13:04] ogra_: desktop [13:04] oh4, i.e. not some remote cloud system or container or some such [13:04] k === faenil_ is now known as faenil [13:04] yep, my workstation here at home [13:04] (that should rule out any kernel issues then) [13:04] Bug #1658086 opened: profile has merged rule with conflicting x modifiers [13:04] oh4, also using the default kernel from the install ? [13:05] correct, ogra_ [13:05] hmm, weird [13:05] no mods...fresh install yesterday [13:05] even ran full upgrade and nothing [13:06] yeah, snapd should just run then ... [13:06] do you see anything intersting grepping fro snapd in syslog perhaps ? [13:06] *for [13:09] following 'egrep -nri "err|warn|fail" /var/log/syslog", I see the following [13:09] https://www.irccloud.com/pastebin/BfvADh36/ [13:09] just grep for snap or snapd [13:10] PR snapd#2673 opened: cmd: add fault injection support code [13:10] but those errors are from when I attempted to use 'snap install canonical-livepatch', I believe [13:11] here some more just for snap [13:11] https://www.irccloud.com/pastebin/4avvevRr/ [13:11] it looks like it started at some point?...hmm [13:12] or maybe it try to start when I run 'snap install ' [13:12] not sure [13:15] oh4, well, looks like snapd starts but then fails when the livepatch thing comes into play [13:16] does "snap list" work ? [13:16] nope, snap list gives the same error [13:16] error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps: dial unix /run/snapd.socket: connect: connection refused [13:17] what does: dpkg -l snapd return as version ? [13:18] ii snapd 2.20.1ubuntu1 amd64 Tool to interact with Ubuntu Core Snappy. [13:21] thats running here as well on all my machines ... strange [13:21] might need a livepatch kernel person? [13:21] zyga, what were the magic commands to clear up all snap related bits on a classic install ? [13:22] popey, yeah, but first we cant even have the core snap installed [13:22] so first i'D like to get the livepatch snap completely ripped out and snapd into a virgin state [13:23] the livepatch snap seems to be sitting in queue now so starting snapd will immediately try to run it and fall flat on its face [13:25] ogra_: I don't know if they work now [13:25] ogra_: just prune snapd [13:25] ogra_: er. purge [13:25] purge you mean [13:25] ogra_: that should do the same [13:25] oh4, sudo apt purge snapd [13:25] then install it again [13:26] yep [13:27] and then try something like: sudo snap install htop [13:27] or snap install hello or so [13:27] that should install the core snap alongside [13:27] after that see if snap list then works === ben_r_ is now known as ben_r [13:49] Bug #1658086 changed: profile has merged rule with conflicting x modifiers [13:55] diddledan, hey, nice corebird update! Would you mind writing up on the steps you went through to get xdg-open working so others can follow your lead? [13:56] I'm hacking https://github.com/nextcloud/nextcloud-snap . If I change the apache.conf file (which is from the apache-customizations part) how do I rebuild the snap with just those changes? [13:56] thanks. I don't think I did anything except installing snapd-xdg-open via apt [13:56] where would be appropriate to post that? I can pop it on my own site but that won't be very discoverable.. [13:57] diddledan, is your snapcraft.yaml anywhere I can peek at? [13:58] yes, it's on launchpad git: https://git.launchpad.net/~diddledan/+git/corebird?h=master [13:58] the direct link to the yaml: https://git.launchpad.net/~diddledan/+git/corebird/tree/snapcraft.yaml [13:59] diddledan, I wonder if it is now part of desktop-gtk3 [14:00] not sure. all I could discern was that the apt package snapd-xdg-open was required and once installed everything "just works" [14:01] I think it would be nice for snapd deb to depend or recommend that package - it's not discoverable that you need to install it for xdg-open to work [14:01] diddledan, well I do have it installed but only yours actually gets it done [14:02] seb128, Trevinho would you have an idea about this? ^ [14:02] odd [14:03] maybe other snaps aren't actually using the xdg-open mechanism but trying to call things directly [14:03] I can try digging into xorebird source to see whether they shell-out or call the dbus directly [14:03] diddledan, that would explain it for some, but not all (I don't think the recent kde frameworks based apps are different) [14:04] or maybe it is a case like that [14:07] jdstrand, when you have a minute, may I ask you to review https://myapps.developer.ubuntu.com/dev/click-apps/6219/rev/2/ ? the same warning as my webbrowser-app upload the other day is blocking publication [14:07] kyrofa_: is there any reason we can't have "AllowOverride All" for the nextcloud install directory, to use the .htaccess file in there? I'm not sure the "Include" directive in your apache.conf is doing what we need it to do... [14:08] mhall119: I'll add a todo for the review tools for Exec= so at least if it hits the store, people will get the feedback [14:13] sergiusens, diddledan, what is the question? [14:15] seb128, xdg-open (again :-) ) [14:16] ok, the way that corebird calls URLs is via GLib: GLib.AppInfo.launch_default_for_uri (uri, null); [14:16] seb128, corebird-diddledan works just fine, wondering why others don't and if there is some sort of guide for this [14:17] sergiusens, gio should work fine [14:18] if the snapd-xdg-open is installed on the system [14:18] which mvo is looking at getting installed by default I think (that was a while ago and I didn't see any update) [14:19] popey: it is snappy. I responded in the bug [14:27] seb128, great, so if an app in snap calls xdg-open it needs to be provided in the snap? [14:28] Or is this a zyga question? [14:29] jdstrand, thanks! [14:29] sergiusens, it should be used from the core snap (where we install the script yb default) [14:30] though weather snap-confine allows execution is indeed actually a zyga question [14:30] oSoMoN: yw [14:31] sergiusens: iirc, no. the xdg-open is in /usr/local/bin in the core snap and snaps have the permissions to call that [14:32] I may be misremembering-- the way we do xdg-open is a little twisty [14:32] but I don't think the snap has to ship it [14:34] in fact it breaks if you ship it [14:34] because then the distro script goes to /usr/bin and overrides the core script in /usr/local/bin [14:36] (or rather to $SNAP/usr/bin) [14:49] PR snapd#2672 closed: cmd: ensure that all .c files have a -test.c file [14:50] PR snapd#2640 closed: interfaces: allow querying added security backends [14:52] thanks jdstrand [14:55] seb128: sorry, I was not pushing snapd-xdg-open recently :/ [14:56] mvo, no worry, I just mentioned it because I think you said that it was on some of your backlog [14:56] PR snapd#2674 opened: snap: show price in `snap info` [14:59] Bug #1657752 changed: 'snap find' doesn't tell me the price of a snap I have bought [14:59] seb128: it is still there, keeps getting pushed aside by more important tasks [15:03] mvo, no worry, thanks for the status update [15:04] PR snapd#2630 closed: many: detect potentially insecure use of snap-confine [15:13] PR snapcraft#1060 opened: options: if host is 32bit use the relative backward compatibility architecture [15:24] jdstrand: thanks! [15:27] jdstrand: hey, this has been reviwed by two other people and waits for a month for a review; I think we should just merge it and carry on; I have a branch that drops privs around argument parsing and I plan on landing it before actually using this new (parser) module. [15:27] jdstrand: https://github.com/snapcore/snapd/pull/2416 [15:27] PR snapd#2416: cmd/snap-confine: add snap-confine command line parser module [15:28] *reviewed [15:28] jdstrand: unless you critically want to review it I plan on merging it when it turns green [15:29] zyga: as agreed to earlier, this is behind a couple of other things and iirc, tyhicks and I felt it needed a review. please talk to ratliff and tyhicks if you want that prioritized ahead of the current work [15:30] also, it is a bit unfair to characterize it in the way you did. yes, it has been open for a month, but it also has never been on the critical path for anything [15:31] ogra_: Jan 20 15:29:14 localhost.localdomain kernel: audit: type=1400 audit(1484926154.100:17): apparmor="DENIED" operation="exec" profile="snap.core.hook.configure" name="/bin/systemctl" pid=1378 comm="configure" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 [15:31] that is interesting but I guess that is just normal confinement and core isn't taken differently [15:38] not to mention, part of that month was a bunch of holidays :) [15:40] morphis_, see rthe other channel :) [15:45] ogra_: the above is a different problem [15:46] ogra_: the access to /run/snapd.socket is a thing I've filed a bug for some weeks ago [15:46] oh [15:46] yeah, core has strict confinement by default [15:47] mcphail, doing that wastes resources because it crawls looking for that file on requests. The idea was to disable it in order to obtain better performance on low-end hardware (e.g. the rpi2) === kyrofa_ is now known as kyrofa [15:48] mcphail, my research led me to believe the Include was equivalent but had the downsides I mentioned in the comment [15:50] ogra_: guess we need an interface or so [15:51] could be, not sure, i think pstolowski might know more how it is supposed to work in core [15:51] i'd actually not expect an interface to be needed here === chihchun is now known as chihchun_afk [15:58] zyga: hey - I'll set aside this seccomp work and review the arg parsing PR [15:58] PR snapd#2675 opened: asserts: implement SuggestFormat to help avoid specifying the wrong format iteration for an assertion [15:58] that code is in too critical of a section to not receive a close security review [16:03] kyrofa: I'm still experimenting, but it works if I AllowOverrides but not with the Include. I'll keep hacking. Hadn't thought of htaccess causing a performance hit [16:05] mcphail, yeah, check this out: https://httpd.apache.org/docs/2.4/misc/perf-tuning.html [16:07] PR snapcraft#1061 opened: Fix Exec key in desktop files for apps named like their parent package (LP: #1658123) [16:08] tyhicks: thanks! [16:08] jdstrand: ack [16:08] Looks like we really do need to get this in the conf file if possible, although I don't think performance gains are worth the loss in functionality if we can't get it to work [16:09] jdstrand: (I didn't think of the holidsys, sorry about that) [16:10] mcphail, agreed [16:10] mcphail, so it works with no other changes if you just allowoverride all ? [16:11] ogra_, i'm not sure what was the question... was it far it the backlog? looks like it's not about snapd.socket again;) ? [16:12] pstolowski, yeah, that tricked me too on first sight ;) morphis_ is actually calling systemctl there from his core config hook [16:12] kyrofa: i've made a few changes, including changing that alias for acme-challenge. I need to unpick them now and see what breaks [16:13] pstolowski, and gets a denial ... should that work ? [16:17] ogra_, oh, sorry, i'm familiar with that.. zyga may know? [16:18] *i'm not* [16:18] PR snapd#2676 opened: cmd: collect string utilities in one module, add missing tests [16:18] ogra_, how does confinement work on the core snap? [16:19] ogra_, obviously on a normal snap a denial would be expected [16:19] kyrofa, heh, no idea, thats a snapd/snap-confine question [16:19] ogra_, does the core snap have any apps? [16:19] nope [16:19] ogra_, that'd be a good way to experiment-- make an app and see if it's confined [16:19] but it is supposed to have a config hook option [16:19] I suspect it is [16:20] But then... it's trying to execute stuff within it so [16:20] Odd [16:25] davidcalle: hi! you probably have in your email something about a new version of the security whitepaper [16:25] davidcalle: but if not, I just updated it for a bunch of series 16 items, urls, etc [16:27]