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
I'm seeing much more than that, installing on noble:
Setting up onboard (1.4.1-5ubuntu2) ...
/usr/lib/python3/dist-packages/Onboard/Appearance.py:924: SyntaxWarning:
invalid escape sequence '\w'
_key_ids_pattern = re.compile('[\w-]+(?:[.][\w-]+)?', re.UNICODE)
Same here:
Setting up rhythmbox-plugins (3.4.7-2ubuntu2) ...
/usr/lib/x86_64-linux-gnu/rhythmbox/plugins/lyrics/AstrawebParser.py:64:
SyntaxWarning: invalid escape sequence '\/'
url = re.split('(\/display[^"]*)', entry)[1]
Public bug reported:
This concerns libdpkg-perl 1.22.4ubuntu5 in Ubuntu noble.
In /usr/share/perl5/Dpkg/Vendor/Ubuntu.pm, there is this bit:
# Debian enables -fstack-clash-protection but it causes troubles on armhf
# (which are not fully analyzed as of writing this); disable it there in
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
Seeing some strange "Device or resource busy" errors on the
/usr/bin/nvidia-debugdump file, seemingly due to Nvidia lossage. Closing
as likely unrelated to the packaging.
** Changed in: nvidia-graphics-drivers-535 (Ubuntu)
Status: New => Invalid
--
You received this bug notification
Public bug reported:
This concerns nvidia-utils-535 (535.161.07-0ubuntu3) in Ubuntu noble.
I had already installed nvidia-cuda-toolkit, and then...
# apt-get install nvidia-utils-535
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested
On an installed system, with both the aforementioned settings disabled,
the display still blanks (black screen) but does not power down. "xset
-q" run on the system via ssh shows "DPMS is Disabled".
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
apport information
** Attachment added: "ProcCpuinfoMinimal.txt"
https://bugs.launchpad.net/bugs/1973298/+attachment/5589672/+files/ProcCpuinfoMinimal.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
apport information
** Attachment added: "ProcEnviron.txt"
https://bugs.launchpad.net/bugs/1973298/+attachment/5589673/+files/ProcEnviron.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1973298
apport information
** Tags added: apport-collected
** Description changed:
This concerns ayatana-indicator-application 22.2.0-1 in Ubuntu jammy.
When I am logged into an Xfce session, I see this:
# loginctl list-sessions
SESSION UID USER SEAT TTY
4
Public bug reported:
This concerns virtualbox-guest-x11 6.1.32-dfsg-1build1 in Ubuntu jammy.
I am running the Xubuntu (Xfce) desktop inside of a VirtualBox host
(5.2.42-dfsg-0~ubuntu1.18.04.1) on Ubuntu bionic.
The system boots fine, and I get to the lightdm login prompt without
issue. Shortly
Public bug reported:
This concerns ayatana-indicator-application 22.2.0-1 in Ubuntu jammy.
When I am logged into an Xfce session, I see this:
# loginctl list-sessions
SESSION UID USER SEAT TTY
40 root
c2 1000 skunk seat0
2
Public bug reported:
This concerns virtualbox-guest-x11 6.1.32-dfsg-1build1 in Ubuntu jammy.
When I am logged in to an Xfce session, the view from loginctl(1) is as
follows:
# loginctl list-sessions
SESSION UID USER SEAT TTY
40 root
c24
Public bug reported:
This concerns ca-certificates-java 20190909 in Ubuntu jammy.
Seen during installation of Java packages:
[...]
Setting up libatk-wrapper-java (0.38.0-5build1) ...
Setting up default-jdk-doc (2:1.11-72build2) ...
Setting up libatk-wrapper-java-jni:amd64
*** 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
On further digging, I've found that this issue is due to an AppArmor
rule, which for some reason was treating localhost differently (as IPv6)
than a regular network address (IPv4). Closing.
** Changed in: xrdp (Ubuntu)
Status: New => Invalid
--
You received this bug notification because
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:
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
Public bug reported:
This concern pipewire 0.3.48-1ubuntu1 in Ubuntu jammy.
I log into an installed system via ssh, and I see
skunk@darkstar:~$ ps auxww | grep skunk
root 13771 0.5 0.1 19772 12224 ?Ss 07:35 0:00 sshd: skunk
[priv]
skunk 13774 5.4 0.1 17160 9940 ?
** Tags added: jammy
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1965923
Title:
rc.apparmor.functions should not mount /sys/kernel/security inside a
chroot environment
To manage notifications
** Tags added: jammy
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1966034
Title:
Request: Add Xubuntu trusty backdrop to xubuntu-wallpapers
To manage notifications about this bug go to:
Public bug reported:
This concerns xubuntu-desktop 2.240 in Ubuntu jammy. (Please redirect
this bug to a more suitable package if appropriate.)
I am testing the Xubuntu 22.04 live desktop system, running from a
daily-build ISO. I do not want the display to blank, nor switch off,
when the system
** Tags added: jammy
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1966048
Title:
xrdp fails to bind to localhost
To manage notifications about this bug go to:
Public bug reported:
This concerns xrdp 0.9.17-2ubuntu2 in Ubuntu jammy.
I want to have xrdp listen on a localhost port. When I configure the
server to use
[Globals]
...
port=tcp://.:3389
in /etc/xrdp/xrdp.ini, and I attempt to start the server, I get an
error:
#
Public bug reported:
This concerns xubuntu-wallpapers 22.04 in Ubuntu jammy.
Please add the Xubuntu backdrop from the trusty release, i.e.
https://3.bp.blogspot.com/-pLKk0mvZIQE/U05l_GluNyI/SPM/X6PzqUZhH_s/s1600/xubuntu-
trusty.png
I miss that mouse.
** Affects: xubuntu-artwork
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
Public bug reported:
This concerns plymouth-theme-xubuntu-logo 22.04 in a current daily build
of the upcoming Jammy release of the Xubuntu Live ISO. (If this issue
belongs to a different package, please redirect accordingly)
Normally, when you reboot the system after a live session, you are
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
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
Bugs, which is subscribed to Ubuntu.
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
KillUserProcesses=yes is a sledgehammer of a solution. I would advise
just removing the geoclue package.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1871728
Title:
geoclue agent process persists
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:
I've confirmed that, as of focal, the /boot/efi/EFI/ubuntu/ directory no
longer needs to be present in order for the grub-efi-amd64 package to
install the bootloader files. Even /boot/efi/EFI/ does not need to be
there; it will be created. This issue still appears to exist on the
Debian side,
Public bug reported:
This concerns grub-efi-amd64 2.04-1ubuntu26 in Ubuntu focal.
Currently, when grub-efi-amd64 (or grub-efi-amd64-signed) is installed
or reconfigured, the following steps occur:
1. Package postinst script runs
2. postinst checks if /boot/grub/x86_64-efi/core.efi is
Public bug reported:
This concerns grub-pc 2.04-1ubuntu26 in Ubuntu focal.
I have the following packages installed. Note that grub-pc has been
removed but not yet purged:
root@xubuntu:/# dpkg -l | grep grub
ii grub-common 2.04-1ubuntu26
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"
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.
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
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
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
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
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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1872564
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
This bug was reported three years ago in Debian:
https://bugs.debian.org/863227
** Bug watch added: Debian Bug tracker #863227
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863227
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
I wouldn't expect dpkg to know about the database files, but they should
at least be deleted by a package script (prerm?) when the package is
removed/purged.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to 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 onboard 1.4.1-2ubuntu7 in Ubuntu focal.
Seen during package installation:
[...]
Setting up onboard (1.4.1-2ubuntu7) ...
/usr/lib/python3/dist-packages/Onboard/LayoutLoaderSVG.py:447: SyntaxWarning:
'str' object is not callable; perhaps you missed a comma?
Public bug reported:
This concerns lightdm-gtk-greeter-settings 1.2.2-3 in Ubuntu focal.
Seen during package installation:
[...]
Setting up lightdm-gtk-greeter-settings (1.2.2-3) ...
/usr/lib/python3/dist-packages/lightdm_gtk_greeter_settings/helpers.py:281:
SyntaxWarning: "is" with a literal.
Public bug reported:
This concerns command-not-found 20.04.2 in Ubuntu focal.
The apt-get invocation largely tells the story:
# apt-get --purge --autoremove remove command-not-found
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following
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
This bug has LP: 1871726 as a quasi-parent.
That one system-config-printer process shown in session-status is
deceptive; ps(1) shows a much larger number of processes still remaining
from the login session. When the s-c-p process goes away, however, all
the others follow. The impact of this
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
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
Related: LP: #1877528
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1871726
Title:
"systemd --user" and child processes fail to exit when user logs out
To manage notifications about this bug go
Public bug reported:
This concerns system-config-printer 1.5.12-0ubuntu1 in Ubuntu focal.
I log into the Xfce desktop, and then logout. The screen returns to the
LightDM login screen.
A few minutes later, "loginctl list-sessions" shows the following:
SESSION UID USERSEAT TTY
Oliver and Łukasz, thank you for following this up.
So that I understand, in focal, is the fix part of the transitional
package, not in the snap?
The former is described as "This is a transitional dummy package. It can
safely be removed," but would removing it then remove Chromium as an x
I'm not sure that this new title is accurate, as the error condition is
brought about specifically by an unusual (albeit legal) way of starting
the X session. My scenario involved xrdp, but I could see this happening
with an older display manager (xdm?) that does not recognize XDG
xsession files.
To elaborate on the situation in Ubuntu focal, as there have been some
improvements:
* grub-reboot(8) now works even when GRUB_DEFAULT != "saved", so that is
out of the picture. I've edited the title of this bug accordingly.
* Both the man page and --help text for grub-set-default(8) indicate
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
I've confirmed that this issue is still present in Ubuntu focal.
** Changed in: grub2 (Ubuntu)
Status: Incomplete => New
** Tags added: focal
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
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.
Autologin is not in use. The only unusual aspect of this login is that
it is via xrdp, and because no argument is passed to the initial
/etc/X11/Xsession invocation, it uses the default x-session-manager ->
gnome-session . If the user logs in via the console, xfce4-session is
used instead, masking
*** This bug is a duplicate of bug 1871955 ***
https://bugs.launchpad.net/bugs/1871955
Looks like a misplaced double-semicolon:
--- /var/lib/dpkg/info/grub-efi-amd64-signed.postinst 2020-04-09
07:00:04.0 -0400
+++ /tmp/grub-efi-amd64-signed.postinst 2020-04-09 22:16:11.243539503
Public bug reported:
This concerns update-inetd 4.50 in Ubuntu focal.
Observed during package installation:
[...]
Setting up finger (0.17-17) ...
Setting up update-inetd (4.50) ...
Setting up fingerd (0.17-17) ...
Use of uninitialized value $_ in pattern match (m//) at
Public bug reported:
This concerns gnome-session-bin 3.36.0-2ubuntu1 in Ubuntu focal.
When I log into a Xubuntu desktop via xrdp, an error occurs, and the
session terminates before the desktop is even drawn on the screen.
I looked in syslog, and saw this:
Apr 9 12:12:23 test-ubuntu64
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
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
Public bug reported:
This concerns geoclue-2.0 2.5.6-0ubuntu1 in Ubuntu focal.
I am using the Xfce desktop. When a user logs in, a
/usr/libexec/geoclue-2.0/demos/agent process is started.
However, when the user logs out, and the associated "systemd --user"
instance is killed, the geoclue
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
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 tumbler 0.2.8-1 in Ubuntu focal.
Symptom: When I log into the Xubuntu desktop environment, the desktop
begins to appear on the screen, but then the X server dies and I am
unceremoniously returned to the LightDM login screen.
If I uninstall tumbler, then I can
Public bug reported:
This concern chromium 80.0.3987.162 (snap package) in Ubuntu focal.
After installing the package, update-alternatives(1) cannot set x-www-
browser to point to /usr/bin/chromium-browser:
# update-alternatives --set x-www-browser /usr/bin/chromium-browser
Public bug reported:
This concerns sgt-launcher version 0.2.5-0ubuntu1 in Ubuntu focal.
I see the following when installing the package:
Setting up sgt-launcher (0.2.5-0ubuntu1) ...
/usr/lib/python3.8/subprocess.py:838: RuntimeWarning: line buffering
(buffering=1) isn't supported in binary
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
Bugs, which is
Hi Carolyn,
This bug concerns usb-creator specifically, not the general USB 3.0
mounting behavior of Linux. Please do not mark this bug as a duplicate
of #792085.
** This bug is no longer a duplicate of bug 792085
Automatic remount of safely removed USB 3.0 drive
--
You received this bug
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
Bugs, which is subscribed to Ubuntu.
Scott, thank you for providing the script, and the analysis that led to
it. I've run into this issue numerous times but have not been able to
suss out exactly what leads to it such that it can be reproduced.
I've linked a relevant Debian bug, which appears to address the same
issue, and was filed
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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1784499
I think there's a good case to get rid of those Conflicts:, at least for
the package combinations that make sense. BIOS+EFI definitely makes
sense, IMO.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
My understanding is that grub-pc conflicts with grub-efi-amd64 (and
other top-level GRUB packages), so having both installed shouldn't even
be possible. (I've filed a bug report on the Debian side to address
this, as this situation is not ideal: https://bugs.debian.org/904062)
And that if you want
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
Public bug reported:
This concerns grub-pc 2.02-2ubuntu8.2 in Ubuntu 18.04/bionic.
I have GRUB configured to do a five-second countdown (no menu) on boot:
GRUB_TIMEOUT_STYLE=countdown
GRUB_TIMEOUT=5
Strangely enough, on a "Dell Precision Workstation" PC that I have here,
the "5"
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:
I see that /etc/apparmor.d/abstractions/gnome in Ubuntu 18.04/bionic has
this line...
owner @{HOME}/.config/gtk-3.0/* r,
...which covers the settings.ini file. So this should no longer be an
issue.
** Changed in: firefox (Ubuntu)
Status: New => Fix Released
--
You received
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
Bugs, which is subscribed to Ubuntu.
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 =>
Philip, wouldn't such a debconf question be closely related to the
existing question on whether to install to the EFI removable media path?
Because if you're not putting things into EFI/ubuntu/ (or EFI/debian/),
then you'd be putting them into EFI/BOOT/ ...
--
You received this bug notification
Hmmm, interesting!
I wouldn't hold out too long on giving the friendly tools smarts
vis-a-vis conditionals, since that kind of logic isn't necessarily
straightforward (i.e. can be hard/time-consuming to implement), it's not
necessary for power/paranoid users (we're happy resorting to a text
/etc/apparmor.d/abstractions/ubuntu-browsers.d/multimedia in Ubuntu
18.04/bionic contains the fix.
Marking the Firefox bug as Invalid, since the issue was fixed by
updating the AppArmor abstraction. (I.e. no change to the firefox
package was/is needed.)
** Changed in: firefox (Ubuntu)
Does this issue still arise with Firefox 60+? I've encountered various
DBus VFS-related denials with Firefox under AppArmor, but not this
particular one.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
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
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
The Firefox AppArmor profile shipped in Ubuntu 18.04/bionic includes
this rule, so this should no longer be an issue.
** Changed in: firefox (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
The Firefox AppArmor profile shipped in Ubuntu 18.04/bionic includes a
rule for /usr/share/distro-info/*.csv, so this should no longer be an
issue.
** Changed in: firefox (Ubuntu)
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs,
Hello Jean-Philippe, do you still see this issue if those AppArmor
permissions are commented out?
Are you using the fglrx driver?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1553708
Title:
Has anyone observed any undesirable behavior from Firefox when access to
these mount-related DBus services is denied?
It's not clear to me why Firefox is even calling these in the first
place, and given that mounts can include NFS servers and the like, I'd
just as soon deny this access if there's
1 - 100 of 872 matches
Mail list logo
