This bug was fixed in the package apparmor - 2.8.95~2430-0ubuntu5.2
---
apparmor (2.8.95~2430-0ubuntu5.2) trusty-proposed; urgency=medium
* debian/patches/php5-Zend_semaphore-lp1401084.patch: allow php5
abstraction access to Zend opcache files (LP: #1401084)
* debian/patches/d
** Branch linked: lp:ubuntu/trusty-proposed/rsyslog
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1425398
Title:
Apparmor uses rsyslogd profile for different processes - utopic HWE
To manage notifi
** Branch linked: lp:ubuntu/trusty-proposed/apparmor
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1425398
Title:
Apparmor uses rsyslogd profile for different processes - utopic HWE
To manage notif
Simon, that is a different issue unrelated to this update. It is being
tracked in bug #1373070.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1425398
Title:
Apparmor uses rsyslogd profile for differ
Oddly enough, I'm still seeing some variation of this error:
May 21 12:27:28 xeon kernel: [95104.918686] audit: type=1400
audit(1432225648.230:57): apparmor="DENIED" operation="sendmsg"
info="Failed name lookup - disconnected path" error=-13
profile="/usr/sbin/rsyslogd" name="dev/log" pid=3444 com
For the apparmor trusty SRU, I reproduced the failure with the source
for apparmor 2.8.95~2430-0ubuntu5.1 from trusty-updates with a hardware
enablement kernel and confirmed that apparmor 2.8.95~2430-0ubuntu5.2
addresses the issue. I also verified that the rest of the apparmor
regression tests pass
Here is the patch to address the apparmor userspace component of this
bug as part of a trusty SRU. It's already been addressed in utopic and
later.
** Patch added: "tests-workaround_for_unix_socket_change-lp1425398.patch"
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1425398/+attachm
This bug was fixed in the package rsyslog - 7.4.4-1ubuntu2.6
---
rsyslog (7.4.4-1ubuntu2.6) trusty-proposed; urgency=medium
* debian/usr.sbin.rsyslog: grant read access to /dev/log to cope with
behaviorial change of apparmor in utopic HWE kernel (LP: #1425398)
-- Steve Beattie
Works here too, thanks!
** Tags removed: verification-needed
** Tags added: verification-done
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1425398
Title:
Apparmor uses rsyslogd profile for differe
It seems that issue is gone with this fix.
1. Installed the package from trusty-proposed
# LANG=C apt-cache policy rsyslog
rsyslog:
Installed: 7.4.4-1ubuntu2.6
Candidate: 7.4.4-1ubuntu2.6
Version table:
*** 7.4.4-1ubuntu2.6 0
400 http://archive.ubuntu.com/ubuntu/ trusty-proposed/mai
Hello Pavel, or anyone else affected,
Accepted rsyslog into trusty-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/rsyslog/7.4.4-1ubuntu2.6 in a few
hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://
ACK on the debdiff in comment #20. Uploaded for processing by the SRU
team. Thanks!
** Changed in: rsyslog (Ubuntu Trusty)
Status: Triaged => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.ne
** Description changed:
- Hi.
+ [rsyslog impact]
+ This bug prevents rsyslog from receiving all events from other services on
trusty when the utopic-hwe (and newer) kernels are used. The rsyslog SRU adds
an additional permission (read access to /dev/log) to the rsyslog apparmor
policy to allow
It turns out that there is a small bit of the AppArmor userspace that
needs to be addressed, the regression tests need to be slightly adjusted
to take the permissions change into account.
** Changed in: apparmor (Ubuntu Trusty)
Status: Invalid => In Progress
** Changed in: apparmor (Ubuntu
The issue here is that one end of the socket is an fs socket and the
other end is anonymous. When the check is done from the socket at the
anonymous end, the check is being dropped.
the patch is a backport of what is in utopic/vivid but is currently
untested. I am building a test kernel
** Patch
** Tags added: patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1425398
Title:
Apparmor uses rsyslogd profile for different processes - utopic HWE
To manage notifications about this bug go to:
h
John, what changes are needed kernel side to address this issue?
Attached is a debdiff to address the rsyslog policy side of things.
** Patch added: "rsyslog_7.4.4-1ubuntu2.6.debdiff"
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1425398/+attachment/4383669/+files/rsyslog_7.4.4-1ubu
Pavel, note that Steve closed the rsyslog/vivid task because that has
been fixed; the rsyslog/trusty task is still open, as are the kernel
portions of the bug.
Thanks
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launch
Also if you read comments of other Ubuntu _developers_, they are rather
confident that the bug is in Utopic HWE for Trusty
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1425398
Title:
Apparmor uses
As I said before, I don't use Vivid, I use Trusty which is stated to be
supported until 2019!
The bug is against trusty, please don't close it as fixed in an non-LTS
release
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs
The rsyslog apparmor policy is shipped in the rsyslog package, not
apparmor. Opening a task against rsyslog, closing the apparmor userspace
task.
** Also affects: rsyslog (Ubuntu)
Importance: Undecided
Status: New
** Changed in: apparmor (Ubuntu)
Status: Confirmed => Invalid
**
This is fixed in the rsyslog policy in vivid; closing there.
** Changed in: rsyslog (Ubuntu Trusty)
Assignee: (unassigned) => Steve Beattie (sbeattie)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bug
Same problem here (Trusty+HWE kernel) and adding "/dev/log r," to
/etc/apparmor.d/local/usr.sbin.rsyslogd does not help.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1425398
Title:
Apparmor uses rs
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: apparmor (Ubuntu Trusty)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1425398
Tit
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: apparmor (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1425398
Title:
A
** Changed in: linux (Ubuntu Trusty)
Status: Incomplete => Confirmed
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1425398
So after looking into this more it looks like this is actually a bug in
the trusty kernel, that has been fixed on utopic.
Trusty needs a kernel patch and an update to its policy.
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Also affects: apparmor (Ubuntu Trusty
Pavel,
okay thanks, this does sound like a bug in the kernel. I will look into
it more
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1425398
Title:
Apparmor uses rsyslogd profile for different proc
John,
I'm using Ubuntu Trusty with Utopic HWE, so my apparmor is from Trusty.
I didn't install anything from backports or Utopic by hand to not mess package
system and LTS state of distribution.
But somehow the system does not behave like trusty.
Note that I've updated this system from 12.04 w/
Are you using the apparmor user space from trusty or the utopic or
backport apparmor userspace?
When using the trusty userspace the HWE kernel should behave like the
trusty kernel, however when using a newer userspace with the HWE kernel
policy will need to be updated.
Ubuntu have chosen to not u
First of all, Trusty kernel worked somehow differently. It didn't
complain for /dev/log.
Yes, my /etc/apparmor.d/usr.sbin.rsyslogd does not have 'r' for /dev/log:
/dev/log wl,
So does it mean that the rsyslog profile has to be patched for trusty?
Or at least some kind of Utop
Seth is correct,
when a message is sent across a unix based file socket their is a cross
check (one check for the sender, and another for the receiver). In this
case the receiving end of the message (rsyslogd) does not have the
correct permission (r perm).
The reason this is reported with the pid
There's a chance this is the AppArmor "cross profile" IPC check; when
one process performs an IPC operation with a second process, in
different profiles, both profiles have to allow the operation.
If my guess is right, these ought to be silenced by changing:
/dev/log wl,
to
/dev/log rwl,
in
33 matches
Mail list logo
