[Kernel-packages] [Bug 1236455] Re: Running tasks are not subject to reloaded policies
This bug was fixed in the package linux - 3.11.0-15.23 --- linux (3.11.0-15.23) saucy; urgency=low [Brad Figg] * Release Tracking Bug - LP: #1259259 [ Tim Gardner ] * [Config] Build-in ohci-pci - LP: #1244176 linux (3.11.0-15.22) saucy; urgency=low [Brad Figg] * Release Tracking Bug - LP: #1257092 [ Andy Whitcroft ] * [Config] CONFIG_DEBUG_BUGVERBOSE=y - LP: #1252353 [ Benjamin Tissoires ] * SAUCE: (no-up) HID: appleir: force input to be set - LP: #1244505 [ John Johansen ] * SAUCE: (no-up) apparmor: Fix tasks not subject to, reloaded policy - LP: #1236455 [ Kamal Mostafa ] * SAUCE: (no-up) drm/i915: i915.disable_pch_pwm overrides PCH_PWM_ENABLE quirk - LP: #1163720 [ Manoj Iyer ] * SAUCE: Enable earlyprintk via the PL011. - LP: #1248233 [ Paolo Pisati ] * [Config] armhf: RTC_DRV_PL031=y - LP: #1252242 * [Config] armhf: CPU_FREQ=y ARM_HIGHBANK_CPUFREQ=y - LP: #1249397 [ Rob Herring ] * [Config] armhf: PSTORE_RAM=y and PSTORE_CONSOLE=y - LP: #1248492 * SAUCE: net: calxedaxgmac: add mac address learning - LP: #1248233 [ Tim Gardner ] * [Debian] Re-sign modules after debug objcopy - LP: #1253155 [ Upstream Kernel Changes ] * Revert rt2x00pci: Use PCI MSIs whenever possible - LP: #1257037 * Revert epoll: use freezable blocking call - LP: #1257037 * Revert select: use freezable blocking call - LP: #1257037 * Revert ima: policy for RAMFS - LP: #1257037 * ARM: tlb: don't perform inner-shareable invalidation for local TLB ops - LP: #1239800 * ARM: 7855/1: Add check for Cortex-A15 errata 798181 ECO - LP: #1239800 * mfd: rtsx: Modify rts5249_optimize_phy - LP: #1255297 * usb: musb: start musb on the udc side, too - LP: #1257037 * usb-storage: add quirk for mandatory READ_CAPACITY_16 - LP: #1257037 * USB: support new huawei devices in option.c - LP: #1257037 * USB: quirks.c: add one device that cannot deal with suspension - LP: #1257037 * USB: quirks: add touchscreen that is dazzeled by remote wakeup - LP: #1257037 * USB: serial: ftdi_sio: add id for Z3X Box device - LP: #1257037 * xhci: Don't enable/disable RWE on bus suspend/resume. - LP: #1257037 * cifs: Fix inability to write files 2GB to SMB2/3 shares - LP: #1257037 * x86: Update UV3 hub revision ID - LP: #1257037 * cpufreq: s3c64xx: Rename index to driver_data - LP: #1257037 * cpufreq / intel_pstate: Fix max_perf_pct on resume - LP: #1257037 * bcache: Fixed incorrect order of arguments to bio_alloc_bioset() - LP: #1257037 * HID: wiimote: add LEGO-wiimote VID - LP: #1257037 * cgroup: fix to break the while loop in cgroup_attach_task() correctly - LP: #1257037 * mac80211: correctly close cancelled scans - LP: #1257037 * mac80211: drop spoofed packets in ad-hoc mode - LP: #1257037 * mac80211: use sta_info_get_bss() for nl80211 tx and client probing - LP: #1257037 * mac80211: update sta-last_rx on acked tx frames - LP: #1257037 * mac80211: fix crash if bitrate calculation goes wrong - LP: #1257037 * ath9k: fix tx queue scheduling after channel changes - LP: #1257037 * cfg80211: use the correct macro to check for active monitor support - LP: #1257037 * cfg80211: fix warning when using WEXT for IBSS - LP: #1257037 * mwifiex: fix SDIO interrupt lost issue - LP: #1257037 * rtlwifi: rtl8192cu: Fix error in pointer arithmetic - LP: #1257037 * iwlwifi: mvm: call ieee80211_scan_completed when needed - LP: #1257037 * iwlwifi: pcie: add SKUs for 6000, 6005 and 6235 series - LP: #1257037 * jfs: fix error path in ialloc - LP: #1257037 * can: at91-can: fix device to driver data mapping for platform devices - LP: #1257037 * can: flexcan: fix mx28 detection by rearanging OF match table - LP: #1257037 * can: flexcan: flexcan_chip_start: fix regression, mark one MB for TX and abort pending TX - LP: #1257037 * SCSI: BusLogic: Fix an oops when intializing multimaster adapter - LP: #1257037 * SCSI: sd: call blk_pm_runtime_init before add_disk - LP: #1257037 * ecryptfs: Fix memory leakage in keystore.c - LP: #1257037 * raid5: set bio bi_vcnt 0 for discard request - LP: #1257037 * raid5: avoid finding discard stripe - LP: #1257037 * libata: make ata_eh_qc_retry() bump scmd-allowed on bogus failures - LP: #1257037 * md: avoid deadlock when md_set_badblocks. - LP: #1257037 * md: Fix skipping recovery for read-only arrays. - LP: #1257037 * target: Fix assignment of LUN in tracepoints - LP: #1257037 * target/pscsi: fix return value check - LP: #1257037 * vhost/scsi: Fix incorrect usage of get_user_pages_fast write parameter - LP: #1257037 * clockevents: Sanitize ticks to nsec conversion - LP: #1257037 * parisc: Do not crash 64bit SMP kernels on machines
[Kernel-packages] [Bug 1236455] Re: Running tasks are not subject to reloaded policies
Hi, this fixed it for me on saucy too, using linux- image-3.11.0-15-generic from -proposed. Before this kernel update, the virsh blockcopy would not work due to being blocked by apparmor. Regards, Tim Miller Dyck -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1236455 Title: Running tasks are not subject to reloaded policies Status in AppArmor Linux application security framework: Fix Released Status in “linux” package in Ubuntu: Fix Released Status in “linux” source package in Saucy: Fix Committed Status in “linux” source package in Trusty: Fix Released Bug description: As of saucy, if you start /usr/bin/foo under an existing policy defined in /etc/apparmor.d/usr.bin.foo, then reload /etc/apparmor.d/usr.bin.foo with updated permissions, then the running tasks is not subject to the new permissions. A testcase is at http://people.canonical.com/~serge/aa_exec.tgz . This passes in precise, and fails in saucy. This came up in the libvirt regression testsuite. When it tries to virsh attach-device, then the existing libvirt task's policy must be updated to allow it to access the new device image file. The test fails with EACCESS trying to open the image file after loading the new policy. To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1236455/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1236455] Re: Running tasks are not subject to reloaded policies
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- saucy' to 'verification-done-saucy'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-saucy -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1236455 Title: Running tasks are not subject to reloaded policies Status in AppArmor Linux application security framework: Fix Released Status in “linux” package in Ubuntu: Fix Released Status in “linux” source package in Saucy: Fix Committed Status in “linux” source package in Trusty: Fix Released Bug description: As of saucy, if you start /usr/bin/foo under an existing policy defined in /etc/apparmor.d/usr.bin.foo, then reload /etc/apparmor.d/usr.bin.foo with updated permissions, then the running tasks is not subject to the new permissions. A testcase is at http://people.canonical.com/~serge/aa_exec.tgz . This passes in precise, and fails in saucy. This came up in the libvirt regression testsuite. When it tries to virsh attach-device, then the existing libvirt task's policy must be updated to allow it to access the new device image file. The test fails with EACCESS trying to open the image file after loading the new policy. To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1236455/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1236455] Re: Running tasks are not subject to reloaded policies
Verified here on saucy, thanks! ** Tags removed: verification-needed-saucy ** Tags added: verification-done -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1236455 Title: Running tasks are not subject to reloaded policies Status in AppArmor Linux application security framework: Fix Released Status in “linux” package in Ubuntu: Fix Released Status in “linux” source package in Saucy: Fix Committed Status in “linux” source package in Trusty: Fix Released Bug description: As of saucy, if you start /usr/bin/foo under an existing policy defined in /etc/apparmor.d/usr.bin.foo, then reload /etc/apparmor.d/usr.bin.foo with updated permissions, then the running tasks is not subject to the new permissions. A testcase is at http://people.canonical.com/~serge/aa_exec.tgz . This passes in precise, and fails in saucy. This came up in the libvirt regression testsuite. When it tries to virsh attach-device, then the existing libvirt task's policy must be updated to allow it to access the new device image file. The test fails with EACCESS trying to open the image file after loading the new policy. To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1236455/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1236455] Re: Running tasks are not subject to reloaded policies
** Branch linked: lp:ubuntu/precise-proposed/linux-lts-saucy -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1236455 Title: Running tasks are not subject to reloaded policies Status in AppArmor Linux application security framework: Fix Released Status in “linux” package in Ubuntu: Fix Released Status in “linux” source package in Saucy: Fix Committed Status in “linux” source package in Trusty: Fix Released Bug description: As of saucy, if you start /usr/bin/foo under an existing policy defined in /etc/apparmor.d/usr.bin.foo, then reload /etc/apparmor.d/usr.bin.foo with updated permissions, then the running tasks is not subject to the new permissions. A testcase is at http://people.canonical.com/~serge/aa_exec.tgz . This passes in precise, and fails in saucy. This came up in the libvirt regression testsuite. When it tries to virsh attach-device, then the existing libvirt task's policy must be updated to allow it to access the new device image file. The test fails with EACCESS trying to open the image file after loading the new policy. To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1236455/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1236455] Re: Running tasks are not subject to reloaded policies
** Changed in: linux (Ubuntu Trusty) Status: Confirmed = Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1236455 Title: Running tasks are not subject to reloaded policies Status in AppArmor Linux application security framework: Fix Released Status in “linux” package in Ubuntu: Fix Released Status in “linux” source package in Saucy: Fix Committed Status in “linux” source package in Trusty: Fix Released Bug description: As of saucy, if you start /usr/bin/foo under an existing policy defined in /etc/apparmor.d/usr.bin.foo, then reload /etc/apparmor.d/usr.bin.foo with updated permissions, then the running tasks is not subject to the new permissions. A testcase is at http://people.canonical.com/~serge/aa_exec.tgz . This passes in precise, and fails in saucy. This came up in the libvirt regression testsuite. When it tries to virsh attach-device, then the existing libvirt task's policy must be updated to allow it to access the new device image file. The test fails with EACCESS trying to open the image file after loading the new policy. To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1236455/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1236455] Re: Running tasks are not subject to reloaded policies
** Also affects: apparmor Importance: Undecided Status: New ** Bug watch added: Email to apparmor@lists # mailto:appar...@lists.ubuntu.com ** Also affects: linux via mailto:appar...@lists.ubuntu.com Importance: Undecided Status: New ** Changed in: linux Remote watch: Email to apparmor@lists # = None ** Changed in: apparmor Status: New = Fix Released ** No longer affects: linux ** Package changed: apparmor (Ubuntu Saucy) = linux (Ubuntu Saucy) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1236455 Title: Running tasks are not subject to reloaded policies Status in AppArmor Linux application security framework: Fix Released Status in “linux” package in Ubuntu: Confirmed Status in “linux” source package in Saucy: Fix Committed Status in “linux” source package in Trusty: Confirmed Bug description: As of saucy, if you start /usr/bin/foo under an existing policy defined in /etc/apparmor.d/usr.bin.foo, then reload /etc/apparmor.d/usr.bin.foo with updated permissions, then the running tasks is not subject to the new permissions. A testcase is at http://people.canonical.com/~serge/aa_exec.tgz . This passes in precise, and fails in saucy. This came up in the libvirt regression testsuite. When it tries to virsh attach-device, then the existing libvirt task's policy must be updated to allow it to access the new device image file. The test fails with EACCESS trying to open the image file after loading the new policy. To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1236455/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
