The crash is due to AppArmor. Adding the following to the profile for
/usr/lib/chromium-browser/chromium-browser gets things working again:
capability sys_admin,
capability sys_chroot,
owner @{PROC}/[0-9]*/setgroups w,
owner @{PROC}/[0-9]*/gid_map w,
owner
Hi Stuart,
Note that Anacron is not a daemon; it needs to be executed at boot time
and intermittently thereafter (via that cron.d script).
It doesn't work to have Anacron run only at boot time and Cron
thereafter, because Anacron maintains state in /var/spool/anacron/ that
needs to be updated
** Changed in: apparmor (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1471645
Title:
[trusty] [regression]
Chad, what is the intended purpose of that command? Because it's
mistranscribed:
$ dpkg -S $(grep -l /etc/apparmor.d/*)
grep: /etc/apparmor.d/apache2.d: Is a directory
grep: /etc/apparmor.d/cache: Is a directory
grep: /etc/apparmor.d/disable: Is a directory
grep:
Public bug reported:
I am using apparmor-profiles in Xenial.
The AppArmor profiles, by default, are set to "complain" mode by way of
"flag=(complain)" directives written into the profiles themselves.
If I want these profiles to be enforced, then I have to edit each one
and manually delete the
For my part, I'm not seeing DNS issues, and I've got a hostname in my
LDAP server URI.
I'm not sure what goes on under the hood for normal DNS resolution these
days (maybe DNS over TCP is favored now?), but if there's any doubt in
your mind, feel free to drop those lines.
--
You received this
Public bug reported:
I am usinc nscd with nslcd (LDAP lookup daemon) for NSS services via
LDAP.
It is typical to configure nslcd to connect to the actual LDAP server,
and then set up /etc/ldap.conf (which is what NSS/nscd uses for "ldap"
type lookups in /etc/nsswitch.conf) with a server URI of
Chromium continues to fail on Xenial with the title error message when
the currently-shipped AppArmor profile is enforced.
I've updated my profile adjustments to address some new issues that have
cropped up in recent builds of Chromium.
Everyone who wants to get things working again, please add
Minor addendum: It's conceivable that the new line should go into
rather than just the nscd profile. I do see
that the nscd socket is already mentioned there.
I don't know if/why anything else would need access to the nslcd socket,
but that may be a valid use case for other folks.
--
You
Public bug reported:
nslcd is a good program to be covered by an AppArmor profile, as it
communicates with an LDAP server and services queries from arbitrary
local applications.
This new profile used the existing usr.sbin.nscd profile as a starting
point.
** Affects: apparmor (Ubuntu)
Thanks to systemd, I've had to update my setterm invocation in
/etc/rc.local to the following:
setterm --term linux --blank 0 --powerdown 0 >/dev/console
("--powersave off" fails with an "Inappropriate ioctl" error because
rc.local no longer runs directly on the Linux virtual console.)
--
Generalized the title to include terminal devices (e.g. Linux virtual
terminals) as well.
I'd like to see a better way to set this up. Yes, you can add the syslog
user to the dialout and/or tty groups, but that grants access to *all*
serial/terminal devices respectively. This can have security
Public bug reported:
This concerns lightdm 1.18.1-0ubuntu1 in Xenial.
The /lib/systemd/system/lightdm.service file lacks an [Install] clause.
Meaning, that if you do
# systemctl disable display-manager
to prevent LightDM from starting, running
# systemctl enable lightdm
does not
This whole systemd thing is new to me, and I can't say I'm terribly
enamored of it, so I'm not the best person to ask. But by way of
example, I'll point out what a couple other .service files do:
/lib/systemd/system/rsyslog.service:
[Install]
WantedBy=multi-user.target
Spurious dialog observed in remote X session on Xenial install with
accountservice 0.6.40-2ubuntu10.
Enabled xenial-proposed, installed accountservice 0.6.40-2ubuntu11, and
the dialog no longer appears.
I wasn't seeing this problem as badly as some other folks here, but for
my use case, the
Thank you Seth :-) Next rev in each release should have this, right?
No copyright line is needed; this was trivial to derive from the nscd
profile.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
Seth, it seems you're absolutely right.
Denying dgram while the system is up is no big deal, because DNS lookups
go through nscd (or other similar infrastructure) instead of being sent
out directly.
But when the system is starting up, and nscd et al. aren't running yet,
the queries do need to go
Public bug reported:
This concerns unattended-upgrades 0.90 in Xenial.
Here is an excerpt from an e-mail report sent out by u-u after the
upgrade process is completed:
Package installation log:
Log started: 2016-07-06 17:24:21
Preconfiguring packages ...
Maybe make display-manager.service into an actual service file (rather
than a symlink), and have that start whatever /etc/X11/default-display-
manager points to?
What I want is to be able to disable and then re-enable the display
manager starting on boot using similar administrative commands,
Benjamin, what you're seeing appears to be bug #1607535. (That bug
report doesn't quote the "/the fonts/" URL directly, but it links to a
comment that does.
I have a bug report (bug #1575408) against ttf-mscorefonts-installer due
to the "Can't drop privileges" warning, but am assuming that that
Hi Luigi,
This StackExchange posting should answer your question:
https://unix.stackexchange.com/questions/3586/what-do-the-numbers-in-a
-man-page-mean
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
Thank you Dimitry, that is a helpful link.
I've removed the key-file attachment from comment #5, but am unable to
otherwise edit/remove the text.
** Attachment removed: "dbgsym-release-key.asc"
I agree on this key needing to be available in the/an official Ubuntu
keyring package.
For now, because the original key file is not even accessible via HTTPS,
I am attaching a copy of it here. The file is dated 2016-07-04 16:10,
and has the following SHA{256,512} hashes:
This bug appears to have been fixed in 8.32.0-1ubuntu4. Looks like this
was an issue with the Apparmor profile.
rsyslog (8.32.0-1ubuntu4) bionic; urgency=medium
[ Jamie Strandboge ]
* debian/usr.sbin.rsyslogd: updates for bionic (LP: #1766600)
- allow rsyslog modules in multiarch
I have an additional test case that is perhaps more immediate.
Attempting to view a roff file in NFS directly:
$ man ./zlib.3
man: ./zlib.3: Permission denied
No manual entry for ./zlib.3
This fails despite the permissive "/** mrixwlk" rule in the AppArmor
profile. Similar output in
Public bug reported:
I am using AppArmor 2.12-4ubuntu5 on Ubuntu 18.04/bionic.
I have the usr.bin.man profile enforced, and home directories in NFS.
The log excerpt copied below is the result of a single invocation of
"man ls" by an unprivileged user. (The program did display the man page
Bug persists in Ubuntu 18.04/bionic:
# ls /etc/cups
ls: cannot access '/etc/cups': No such file or directory
# apt-get install cups-client
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
An update to the "ldapclient" abstraction has been merged upstream:
https://gitlab.com/apparmor/apparmor/merge_requests/153/diffs?commit_id=ac1d0545f458b11728f2bcb4a7de0567538fa94a
** Changed in: apparmor
Status: New => Fix Committed
** Changed in: apparmor (Ubuntu)
Status: New =>
I think we're going to need more information on how this plugin got in
there in the first place. Being able to map a library in a user-writable
directory doesn't sound terribly safe...
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is
Arrgh... this is not a great way of working (malware could write to that
location and then load in code), but as it is what we've got, I've added
the rule to a forthcoming Firefox profile update.
Incidentally, Olivier, if you've got a line on who's responsible for the
Firefox profile there, it
This issue can be addressed with a manual action, but first you have to
dig into the scripts to diagnose the problem, and really if resolvconf
is installed then it should just work.
Part of this setup involves disabling systemd-resolved, in favor of a
"direct" /etc/resolv.conf, to match the
Dimitri, thank you for laying out the rationale behind the package name.
Since there is good reason for things to be the way they are here, I've
opened a bug on the Debian side for them to address the naming
inconsistency:
https://bugs.debian.org/904152
** Bug watch added: Debian Bug
Public bug reported:
When I install resolvconf on a minimal install of Ubuntu 18.04 (bionic),
I see this:
# apt-get install resolvconf
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
resolvconf
0
Public bug reported:
I am setting up an Ubuntu 18.04 (bionic) system with ifupdown instead of
netplan, as the latter does not meet my needs. I am using resolvconf to
update /etc/resolv.conf from DHCP, as in earlier releases.
Unfortunately, I am not seeing /etc/resolv.conf (actually a symlink to
Public bug reported:
The package that Ubuntu calls "ubuntu-keyring" is present in Debian as
"ubuntu-archive-keyring".
Debian has separate "debian-keyring" and "debian-archive-keyring"
packages, described as follows:
d-k: GnuPG keys of Debian Developers and Maintainers
d-a-k: GnuPG
Thanks Dimitri, greatly appreciated. I haven't found many problems in my
testing of Bionic, but this is the juiciest one so far.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
Steve, Bionic still has the default (commented-out)
#DNSStubListener=udp
in /etc/systemd/resolved.conf .
I've noticed that this breaks Kerberos KDC lookup at a large site,
because the reply is quite large:
# host -t SRV _kerberos._udp.xxx.example.com
;; Connection to
Hi Brian,
This is actually the same issue.
I am seeing the same error message quoted by the original reporter, but
that message is filtered through systemd---it is not direct output from
rsyslogd. What I provided was the direct output, that actually shows
what's going on.
I think this needs to
I am seeing this same error in Bionic. Some further telemetry:
# /usr/sbin/rsyslogd -n
rsyslog internal message (3,-2066): could not load module
'/usr/lib/x86_64-linux-gnu/rsyslog/lmnet.so', dlopen:
/usr/lib/x86_64-linux-gnu/rsyslog/lmnet.so: failed to map segment from shared
object
[v8.32.0
Thanks for looking into this Markus. I'm surprised that the kernel
pieces needed to make this work as expected have yet to be fully
integrated.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
Could this be SRU'ed into Bionic?
18.04LTS currently has version 1.1, so the "Reading database ..." lines
will otherwise afflict it for quite some time to come.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to
Thanks Balint. I've installed the bionic-proposed package, and have not
observed any silently-failed upgrades as before (but of course verifying
it in my use case is tantamount to proving a negative).
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages,
This occurs whether the user logs in (through lightdm) on the console,
or remotely via xrdp.
Running that command, as root, after the user (skunk) has logged in via
lightdm:
# loginctl list-sessions
SESSION UID USER SEAT TTY
20 root
c2 1000 skunk
Public bug reported:
This concerns systemd 245.2-1ubuntu2 in Ubuntu focal.
I am using the Xfce desktop. After the user logs out from a desktop
session, numerous desktop-related processes are left over. Here is a
listing, taken over twenty minutes after logout:
skunk853 0.0 0.2 18912
Note: My use case involves logging into the desktop remotely, via XRDP.
This issue appears to affect other remote-login implementations as well.
Related:
https://github.com/TurboVNC/turbovnc/issues/47
https://bugzilla.redhat.com/show_bug.cgi?id=1149893
This issue is still present in Ubuntu focal.
Here is what I see that needs to happen:
systemd: The /etc/dhcp/dhclient-enter-hooks.d/resolved script should be
renamed to something like 00resolved or aaa_resolved, so that other
packages that install scripts into that directory will have their
Could you try this using lightdm? It's possible that this may be a
display-manager issue.
I did notice that in a different (customized) configuration of Xubuntu,
the user processes still remained after logout, but then killing the
"systemd --user" process resulted in the login session ending.
Public bug reported:
This concerns colord 1.4.4-2 in Ubuntu focal. (xiccd 0.3.0-1 may also be
relevant.)
I log into the Xfce desktop environment, and immediately see an
"Authenticate" window pop up:
Authentication is required to create a color managed device
Password for root:
Public bug reported:
This concerns apparmor 2.13.3-7ubuntu5 in Ubuntu focal.
If I delete a profile from /etc/apparmor.d/, reboot the system, and then
look in /var/cache/apparmor/.0/, I still see a file for the
compiled form of the profile.
The same occurs if the profile is "deleted" by
Public bug reported:
This concerns apparmor 2.13.3-7ubuntu5 in Ubuntu focal.
I have AppArmor actively enforcing policy on my system. In
/var/log/syslog, I see a number of the following two sorts of messages:
May 12 04:44:21 image-ubuntu64 kernel: [ 26.667094] audit: type=1400
Aaaand the upstream has decided they can't/won't fix this issue.
One thing that bothers me about this whole situation is that, in order
for background services like this one to be cleaned up after logout,
they need to behave "correctly." From my point of view, this is
backwards.
When the system
Thanks. I am in complete agreement.
I don't need (or even want) AppArmor to automagically update the kernel
state right after changing something under /etc/apparmor.d/, because
having to do a SIGHUP/restart/etc. is already normal practice. But I do
expect that a reboot/reload will take care of
A related issue: "/etc/init.d/apparmor stop" should invoke aa-
teardown(8). Depending on the semantics of the apparmor "service," this
could also be "/etc/init.d/apparmor unload" or the like. I was surprised
to find that "apparmor stop" was not actually unloading the profiles, as
I had assumed.
That's why I hedged on having something like "apparmor unload". What
you're saying explains why "restart" and "reload" are distinct actions
(I'd never been clear on this), so having a new action that is "like
'stop' but actually does stop apparmor, even though that is not usually
what you want"
Hello John,
I did not take any specific action to unload a profile from the kernel.
Instead, I rebooted the system, under the assumption that this would
wipe the slate clean, with everything reloading cleanly from
/etc/apparmor.d/.
The new profile I developed was under a new filename, because I
Thanks for being on top of this, Sergio. I'm surprised that a LP search
for "boot_id" in this project did not turn up this existing bug report.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
This issue persists in lightdm 1.30.0-0ubuntu3.1 in Ubuntu focal.
I see the warnings not only for pam_kwallet.so, but also its successor
pam_kwallet5.so, as well as pam_gnome_keyring.so (which I do not have
installed). All three of these are referenced in /etc/pam.d/lightdm and
Public bug reported:
This concerns at-spi2-core 2.36.0-2 in Ubuntu focal.
I log into the Xfce desktop as "skunk" via xrdp, and then logout.
A few minutes later, "loginctl list-sessions" shows the following:
SESSION UID USER SEAT TTY
9 0 root
c10 1000 skunk
Also related: LP: #1877532
It's possible that all the lingering processes are due to a couple of
misbehaving applications.
This isn't a great state of affairs (the cleanup process should not be
so fragile that non-cooperative processes can stop it completely), but
it might explain what's going
This bug has LP: 1871726 as a quasi-parent.
Those two processes shown in session-status are deceptive; ps(1) shows a
much larger number of processes still remaining from the login session.
When the two processes go away, however, all the others follow. The
impact of this issue, then, is not
Related: LP: #1877528
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1871726
Title:
"systemd --user" and child processes fail to exit when user logs out
Status in
Public bug reported:
This concerns apparmor 2.13.3-7ubuntu5 in Ubuntu focal.
Saw this during a Firefox test run:
May 29 17:25:32 test-ubuntu64 kernel: [ 818.399967] audit: type=1400
audit(1590787532.023:69): apparmor="DENIED" operation="open"
profile="firefox"
Public bug reported:
This concerns apparmor-profiles 2.13.3-7ubuntu5 in Ubuntu focal.
I use the usr.sbin.nscd profile in enforce mode, and am seeing the
following messages in /var/log/syslog . I don't know if the SIGABRT is
related:
May 27 04:39:56 test-ubuntu64 kernel: [ 199.392521] audit:
Yes, it is still an issue in focal. Was there an update since last year
that should have addressed this?
** Changed in: systemd (Ubuntu)
Status: Invalid => New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd
FWIW, the fix in focal-proposed looks good on my end as well.
I can confirm that the /etc/dhcp/dhclient-enter-hooks.d/resolved script
now has the is-enabled check, and while I won't be able to test out
resolvconf, I regard the updated conditional as equivalent to my
previous known-good workaround
Thank you @ddstreet, I'm happy to see this as well. I'd like to get rid
of the workaround I've been using for this issue:
# dpkg-divert --divert /etc/dhcp/dhclient-enter-
hooks.d/resolved.DISABLED --rename /etc/dhcp/dhclient-enter-
hooks.d/resolved
--
You received this bug notification because
** Tags added: jammy
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1965923
Title:
rc.apparmor.functions should not mount /sys/kernel/security inside a
chroot
Note that the /proc/XX/task/YY/comm denials are addressed in LP:
#1918410.
That leaves two of this sort:
audit: type=1400 audit(1645193286.560:2012): apparmor="DENIED"
operation="mknod" profile="/{,usr/}sbin/dhclient"
name="/run/NetworkManager/dhclient-oob_net0.pid" pid=103303
Note to everyone watching this bug:
The file that John modified above is in the "extra profiles" section of
the upstream AppArmor source repository. It may be found on an Ubuntu
system at
/usr/share/apparmor/extra-profiles/sbin.dhclient
and in jammy, it has his fix.
However, the
This message...
type=AVC msg=audit(1625678140.496:1898): apparmor="DENIED"
operation="open" profile="/{,usr/}sbin/dhclient"
name="/proc/8537/task/8540/comm" pid=8537 comm="dhclient"
requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
...is actually for a different issue, discussed at LP:
Public bug reported:
This concerns apparmor 3.0.4-2ubuntu2 in Ubuntu jammy.
When I run a command like aa-teardown(8), it will mount securityfs on
/sys/kernel/security if this is not already mounted.
On bare metal, this is reasonable. But in a chroot environment, the
command should probably exit
*** This bug is a duplicate of bug 1949970 ***
https://bugs.launchpad.net/bugs/1949970
This appears to have been addressed in bug #1949970 by making use of a
feature of the PAM config. In /etc/pam.d/lightdm, I see e.g.
-authoptionalpam_gnome_keyring.so
-authoptional
Reopening this issue as I am still observing the net_admin denial in
jammy.
** Changed in: cups (Ubuntu)
Status: Expired => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to cups in Ubuntu.
** Also affects: lightdm (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1922414
Title:
ssh-agent fails to start
Public bug reported:
I am seeing this on Ubuntu noble with polkitd 123-3.
After debootstrap'ing a minimal system, I run
# apt-get install linux-generic
which pulls in polkitd as a dependency. In the output, I see the
following:
Setting up polkitd (123-3) ...
Creating group
Tracked down the cause to the Docker host, which runs on jammy, not
knowing about fchmodat2(). The syscall should normally return ENOTSUP
when called with AT_SYMLINK_NOFOLLOW on Linux, but the Docker seccomp
profile causes it to return EPERM, which confuses tar(1). Closing.
** Changed in: tar
Public bug reported:
This concerns tar 1.35+dfsg-3 in Ubuntu noble. This does NOT affect tar
1.34+dfsg-1.2ubuntu1.1 in mantic.
I'm seeing errors like this:
$ tar xvJf /extern/source/chromium_122.0.6261.111.orig.tar.xz --wildcards
Important context from https://lists.debian.org/debian-security-
announce/2024/msg00057.html :
Andres Freund discovered that the upstream source tarballs for xz-utils,
the XZ-format compression utilities, are compromised and inject
malicious code, at build time, into the resulting liblzma5
78 matches
Mail list logo
