[09:53] hi all - anyone around who can have a look at a couple of patches I'm proposing on behalf of Ubuntu Budgie please? https://bugs.launchpad.net/ubuntu/+source/gnome-desktop3/+bug/1703690 [09:53] Launchpad bug 1703690 in gnome-screensaver (Ubuntu) "Add support for Budgie Desktop using GNOME Screensaver" [Undecided,In progress] [10:24] sil2100: Hi there, I've fixed bug 1641912, if you could take a look again, that would be wonderful. :) [10:24] bug 1641912 in gtk+2.0 (Ubuntu Zesty) "Please backport two recent-manager patches" [Critical,In progress] https://launchpad.net/bugs/1641912 [10:25] tsimonq2: sure thing! Looking much better now, should be able to take care of this in around ~15 minutes [10:25] sil2100: Excellent :) [12:08] Can a kind soul please help me understand what is going on in bug 991471? I don't know udisks2 enough and it seems at least I have another disk monitoring daemon running somehow (udev-based?) [12:08] bug 991471 in udisks2 (Ubuntu) "multi-device btrfs filesystem automatically mounted once for each device" [Medium,Confirmed] https://launchpad.net/bugs/991471 [13:36] bdrung_work, http://paste.ubuntu.com/25226575/ <-- that is probably enough to get you what you're after [13:36] it doesnt do the download for you, but gets you probably what you're after before downloading. [13:44] that's a good starting point [14:15] cyphermox or xnox can you help with hanging ubiquity hanging on my laptop while booted from ubuntu 17.10 usb stick to upgrade 16.04 install. [14:15] It seems to have hung during "Removing conflicting operating system files", and isn't doing anything [14:15] http://paste.ubuntu.com/25226720/ - copy and pasted that out of the ubiquity window [14:29] popey, we don't really support "upgrade with ubiquity" path. But I am assuming you are testing things, and found a bug, which we may be able to fix. [14:30] currently supported paths are for 16.04 -> 17.04 upgrade + upgrade from 17.04->devel(17.10) [14:30] if we dont support it, we should remove it [14:30] we will support it from 16.04->18.04 [14:30] oh, okay [14:30] i see [14:30] just not _during_ devel. [14:30] ok, I'll nuke it then. [14:30] popey, but most likely you found something we will need to fix. [14:30] what debug info do i need to file for the bug report? [14:31] popey, could you first dump the logs for me? [14:31] sure thing [14:31] popey, either $ ubuntu-bug ubiquity -> whilst that is running or copy/attach/publish [14:31] /var/log/* /var/log/installer/* [14:31] from the live system, and/or the installed system. [14:31] doing [14:33] tah [14:34] popey, also that log is very helpful. I'm drowning in the snapd and gtk pointless messages without seeing anything useful *sigh* [14:34] it smells like a lot of things are emitting loads of warnings, no idea if any are actually relevant / critical. [14:34] or as in caused the failure you have. [14:35] the "send problem report to the developers" seems to be taking an age [14:40] haha, it's waiting for me, but has a mouse spinner making me think it's busy :) [14:40] lulz [14:43] popey, we try hard for people to give up submitting bug reports?! =) [14:46] xnox: bug 1708182 - anything you need before I nuke this laptop? [14:46] bug 1708182 in ubiquity (Ubuntu) "Ubiquity hung when upgrading to artful from 16.04" [Undecided,New] https://launchpad.net/bugs/1708182 [14:47] could this be some upgrade of GLib breaking things hard? [14:47] oh, but no, nevermind [14:49] upgrading from a live CD there should be no reason for whatever happens on the target filesystem to hang ubiquity. [14:50] so it's not hung in the process-locked-up sense, but hung in the its-doing-nothing sense [14:52] ok [14:53] even so, seems to me like it's mostly just a replace-files job (when you simplify things to the spherical cows level) and you're running things in an unaffected environment [14:53] popey: I'll look at your bug later :) [14:53] ok, any more logs you think you mihght need, or does the bug have it all? [14:55] oh, that's interesting [14:55] it's hung much earlier than I expected [14:57] popey: I think it has all I need [14:57] tjaalton: What does this mean? https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati-hwe-16.04/+bug/1707884/comments/7 [14:57] Launchpad bug 1707884 in xserver-xorg-video-ati-hwe-16.04 (Ubuntu) "GTK3 tooltips are corrupted after latest update" [High,Confirmed] [14:57] partman blew up for some reason [14:58] so not in the in the "grep -q popey /target/etc/passwd && sleep 1000000000" ? [14:58] :) [14:58] my password is neopi :þ [14:59] touche ! [15:02] cyphermox: ok, thanks. nuke time! :D [15:02] * cyphermox replaces that popey grep with ogra next [15:02] :P [15:25] xnox: fyi, i see why the open-iscsi tests are failing, it's actually because of the systemd change (open-iscsi won't start unless it needs to now (condition failed for there being configured iscsi nodes)), working on a fix for it [15:25] smoser: --^ [15:27] tjaalton: I suspect the real problem is you haven't created an apport package hook for xserver-xorg-video-ati-hwe-16.04 this would live in xdiagnose not apport. [15:27] nacc, cool thank you. [15:38] is it ok if I merge base-files from Debian? [15:38] I want to get the MPLs in common-licenses and I suppose deriving from buster is more accurate now too [15:38] jbicha: It's not a trivial merge. I have it on my TODO for later this week. [15:39] ok, thanks [16:45] stgraber, tyhicks, pitti: https://github.com/systemd/systemd/issues/6519 systemd-journald-audit.socket comes up degraded in the default lxd container on ubuntu. It fails at bind() with EPERM due to apparmor deny from the host. Systemd already does mariad of checks and is sensitive to having audit capability (such lxd container does) and ability to open audit socket (also passes as ok). [16:45] should something filter out audit capability for the guest? [16:45] should apparmor deny _opening_ the fd? [16:46] my naive attempt to add ConditionVirtualization=!private-users -> meaning do not start systemd-jounrnald-audit.socket got reverted upstream, as this is not a user-namespace issue per-se. [16:47] bdmurray: yep, i'll fix that for xenial, and prpbably move the apport stuff from xdiagnose to xorg [16:47] here systemd checks for EPERM to open a NETLINK_AUDIT socket https://github.com/systemd/systemd/blob/master/src/basic/audit-util.c#L88 [16:48] maybe jdstrand ^^^^^ [16:48] xnox: so, right now root in an unprivileged container can't access the audit log. But audit namespacing is being worked on and this will eventually work, so dropping the capability or denying it at the apparmor level seems wrong to me. [16:50] right. but is it reasonable to get EPERM on bind() instead of earlier on fd creation with socket()? what good is an audit socket fd, which one will not be able to bind()? [16:51] you'd have to ask whoever wrote the kernel code for that :) [16:52] ROLF [16:53] is it kernel that is giving me EPERM, or apparmor. I got the impression it is apparmor. [16:53] (and I guess /first/ as in without apparmor, kernel would have EPERMed the bind too) [16:54] should be the kernel, I don't think we restrict any of the socket stuff for containers [16:54] lxc config set container-name raw.lxc lxc.aa_profile=unconfined && lxc restart container-name [16:54] that way you won't have apparmor applied at all [16:54] nspawn does seccomp filter of NETLINK_AUDIT. [16:54] I have a lot of [16:54] [2957842.913010] audit: type=1400 audit(1501692226.648:2259): apparmor="DENIED" operation="file_lock" profile="lxd-normal_" pid=13199 comm="(t-daemon)" family="unix" sock_type="dgram" protocol=0 addr=none [16:54] but i have no idea if this is related or not. [16:55] oh, actually red herring - wrong sock_type, no? audit sockets should netlink sock_type or some such?! [16:55] hmm, that looks like apparmor being a bit confused indeed, but shouldn't be related since that's family=unix [16:59] stgraber, hypothetically something unpriviledged could open audit socket, pass it to something priviledged, for the priviledged to bind it. [16:59] but it sounds so wrong for something priviledged, to be binding something unpriviledged. Sounds like a great backdoor. [17:00] stgraber, so i'm guessing if i say "please seccomp filter-out audit socket in lxd by default because of this one silly cosmetic issue with one thing?" you will simply say "no?" right? [17:01] cause i'm inclined to simply carry the patch ConditionVirtualisation=!private-users in the distro for now, to not start audit socket in containers. [17:02] despite it being rejected upstream. [17:07] xnox: yeah, also, liblxc doesn't yet have argument filtering for seccomp, so we'd need to write more code in liblxc, get a new lxc release out, then have that be used in lxd. distro patching the unit seems easier :) [17:07] xnox: we could take the approach that people don't need audit in LXD containers and drop the 3 audit caps which would fix it too, but again, once audit namespacing lands, we'd have to revert and then things will work or break depending on your kernel version, so not ideal [17:15] stgraber, i think there is more to that, as i think when audit namespacing lands, systemd/journald will too need to learn stuff about audit namespaces potentially [17:15] but the host, can never know if something inside is new or old. [17:15] meh. [17:15] the patchsets I've seen so far wouldn't require any special knowledge from systemd in the container [17:16] journald on the host could be extended to know what namespace an audit entry came from too (but not required) [17:16] ack. [17:17] so hypothetically 16.04 with hwe kernel from 18.04 things would just work(tm) [17:17] so ideally I need a check for "i am namespaced, i am not privileged, i have _no_ audit namespace" [17:17] assuming it's in the 18.04 kernel, yes. audit namespacing has been going very slowly :) [17:17] is the audit namespace already known? [17:18] i guess it will be "audit" subsys_name in cgroups?! right. [17:18] /proc/cgroups [17:18] nope, it's going to be a namespace, not a cgroup [17:19] it "may" end up having its own entry in /proc/self/ns/ but right now it looks like it'd just be tied to the user namespace, so the only way to detect support would be to see if you get EPERM [17:20] le sigh [17:20] I don't suppose there's a way to tell systemd to just try to do its thing and if it gets EPERM to give up without considering it a full blown failure? (anything but EPERM should be considered a failure obviously) [17:20] that's the logic we have in a bunch of places now (oom adj score, sysctl, ...) [17:20] for a socket unit, failing to bind, given the whole point of socket activation, sounds like a non-ignorable thing to do. [17:20] i guess i could exetend the socket.unit with FailBind=ignore [17:20] or something [17:21] or I could add a Condition binary that tries to open & bind quickly. and that way condition would fail and the unit will not be started. [17:24] yeah [Socket] supports ExecStartPre [17:25] huh, but that would still fail the unit. [17:43] stgraber, in the kernel it does: if (!capable(CAP_AUDIT_READ)) return -EPERM [17:43] * xnox head desk [17:44] what's the point of capabilities, if they are declared as being there, yet there is no way to know if they are actually available or not. [17:52] xnox: right, capable(CAP_AUDIT_READ) is the same as ns_capable(CAP_AUDIT_READ, 0), so checks against the initial namespace. If the check was done against the container's user namespace, then it would have the capability. [18:02] * xnox ponders if i can move it from audit_bind() to audit_net_init() instead. har har. in the kernel. [18:08] stgraber, is there a way to test, from userspace, against the initial namespace somehow? systemd reads /proc/self/status and read the CapBnd: off there [18:09] hallyn: ^ [18:10] as in test if i do have un-user-namespaced capability or not. [18:11] xnox: not exactly. but you can parse /proc/self/uid_map - if you're not in the initial ns then you have no caps against the initial ns [18:12] so if it looks like '0 100000 65536' then you have no global caps [18:12] and if it lookslike '0 0 4294967295' i do? [18:12] what does uid_map mean? [18:12] xnox: oh and that wouldn't actually help you with the audit namespace as once it's there, you still won't have the cap against the initial ns, it's just that the in-kernel check will now check against your userns cap set rather than init ns cap set [18:12] * xnox will look for documentation on its format. [18:13] xnox: right. uid_map means "container_uid host_uid range", [18:13] see 'man subuid' [18:13] ack thanks. [18:13] \o [18:13] stgraber, i am expecting that kernel will change from capable -> ns_capable when audit namespace is implemented. [18:14] xnox: right, which will be entirely invisible from userspace [18:14] xnox: except that you will now be able to bind() [18:14] stgraber, i'm trying to add code in systemd, such that ConditionCapability=CAP_AUDIT_READ at the moment also requires initial ns. [18:14] stgraber, i'm trying to add code in systemd, such that ConditionCapability=CAP_AUDIT_READ at the moment also requires initial user ns. [18:15] alternatively, send patch to kernel to _move_ the capable check from bind() to init(), and I believe from reading linux source code should make the EPERM return on socket(), rather than on bind() or connect() [18:16] hm, yeah doesn't help [18:16] if i mimic kernel check in systemd, i will not magically get everything working when the kernel changes, sigh. [18:17] basically systemd should bind, and be done with it. [18:19] xnox: in order to talk to the audit subsystem, you probably need 'network netlink ...'. that log message is a unix socket. I'm not sure what it is connecting to [18:22] probably 'network netlink raw,' [18:22] (that is what useradd needed (it uses libaudit)) [18:25] jdstrand, is there a quick check if there is anything like that, in apparmor denies for unprivileged lxd vs privileged one? at the moment I am assuming that I'm not getting an apparmor deny, and it's simply just the kernel giving me an EPERM upon bind(). [18:25] i will look for useradd profiles, and check lxd profiles. [18:25] so never mind. [18:25] (low priority) [18:26] xnox: you should see a denial in the kernel log if it is apparmor. you probably want to sudo sysctl -w kernel.printk_ratelimit=0 [18:29] xnox: and the log would be very clear if it is a netlink denial. that said, DAC is evaluated first so if you aren't root (or have sufficient caps) and trying to access NETLINK_AUDIT, then the kernel will give you EPERM. iirc, apparmor normally gives EACCES, but not sure for networking [18:30] so, everything in backscroll suggests DAC, not apparmor [18:30] (well, except the unix denial, which would need to be investigated) [18:31] jdstrand: thanks for taking a look [18:34] i am on the verge of my comfort zone. but i understand everything that was said so far =) [18:34] and things match source code of linux/systemd so far. will check apparmor configs etc next. === JanC is now known as Guest87139 === JanC_ is now known as JanC === masACC is now known as maswan