snap-based programs complain about locale, permission

Bug #1982401 reported by Paul Eggert
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Snapcraft
New
Undecided
Unassigned
snapd (Ubuntu)
Incomplete
Undecided
Unassigned

Bug Description

This is a followup to Launchpad Bug#1959845, with more information about the bug.

I am running Ubuntu 22.04 LTS on x86-64 with current patches. I have snapd 2.55.5+22.04.

When I run the shell command "chromium --version" and attempt to debug the resulting situation a bit, I see the following:

  $ chromium --version
  /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
  /bin/bash: /home/eggert/.bashrc: Permission denied
  Chromium 103.0.5060.114 snap
  $ echo $SHELL
  /bin/bash
  $ ls -l $HOME/.bashrc
  -r--r--r-- 1 eggert eggert 420 Apr 25 2002 /home/eggert/.bashrc
  $ env | grep en_US
  LC_ALL=en_US.utf8
  $ locale
  LANG=C
  LANGUAGE=
  LC_CTYPE="en_US.utf8"
  LC_NUMERIC="en_US.utf8"
  LC_TIME="en_US.utf8"
  LC_COLLATE="en_US.utf8"
  LC_MONETARY="en_US.utf8"
  LC_MESSAGES="en_US.utf8"
  LC_PAPER="en_US.utf8"
  LC_NAME="en_US.utf8"
  LC_ADDRESS="en_US.utf8"
  LC_TELEPHONE="en_US.utf8"
  LC_MEASUREMENT="en_US.utf8"
  LC_IDENTIFICATION="en_US.utf8"
  LC_ALL=en_US.utf8
  $ locale -a | grep en_US
  en_US.iso885915
  en_US.utf8
  $ LC_ALL=C chromium --version
  /bin/bash: /home/eggert/.bashrc: Permission denied
  Chromium 103.0.5060.114 snap

As you can see, I get some bogus diagnostics about the locale and the .bashrc permissions.

My locale is fine - though evidently snap packages can't use it.

I do have a .bashrc file. This file is not executable and it shouldn't be executable as it's not intended to be a standalone command. It has worked just fine for decades, when I log in via Bash or run Bash in the usual way.

I reported a similar problem with Firefox in Launchpad Bug#1959845, and the response was "this is a bug with the snap packaging of Firefox, not with snapd. Please file a bug with Mozilla upstream". Although I did so here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1753320

their response was that it wasn't a Firefox bug. And now that I see a similar problem with Chromium it appears that this is a snapd issue, not an issue with individual programs.

Revision history for this message
Paul Eggert (eggert-cs) wrote :

One other thing that may be relevant is that I mention .bashrc in my environment:

  $ env | grep bashrc
  ENV=/home/eggert/.bashrc
  BASH_ENV=/home/eggert/.bashrc

Revision history for this message
Paul Eggert (eggert-cs) wrote :

If I unset BASH_ENV, the "Permission denied" message goes away but the local messages remain. But there's nothing wrong with my BASH_ENV, as can be seen from the ". $BASH_ENV" command in the shell transcript below.

  506-day $ echo $BASH_ENV
  /home/eggert/.bashrc
  507-day $ . $BASH_ENV
  508-day $ firefox --version
  /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
  /bin/bash: /home/eggert/.bashrc: Permission denied
  Mozilla Firefox 102.0.1
  509-day $ unset BASH_ENV
  510-day $ firefox --version
  /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
  Mozilla Firefox 102.0.1
  511-day $

Revision history for this message
Alberto Mardegan (mardy) wrote :

Hi Paul, and thanks for reporting this issue. Could you please reproduce the bug again and attach the output of the command

    journalctl -t audit

run shortly after reproducing the issue? I suspect that the issue with the BASH_ENV file is not about it not being executable, but rather AppArmor might be blocking it.

Changed in snapd (Ubuntu):
status: New → Incomplete
Revision history for this message
Paul Eggert (eggert-cs) wrote :

After reproducing the bug, here's the journalctl -t audit output:

Aug 01 08:33:56 day audit[4553]: AVC apparmor="DENIED" operation="open" profile="snap.chromium.chromium" name="/home/eggert/.bashrc" pid=4553 comm="desktop-launch" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000

One more thing. The first time I tried to reproduce the bug (soon after logging in) the symptoms were different and unusual:

$ chromium --version
update.go:85: cannot change mount namespace according to change mount (/var/lib/snapd/hostfs/usr/share/libreoffice/help /usr/share/libreoffice/help none bind,ro 0 0): cannot create directory "/usr/share/libreoffice/help": permission denied
update.go:85: cannot change mount namespace according to change mount (/var/lib/snapd/hostfs/usr/share/xubuntu-docs /usr/share/xubuntu-docs none bind,ro 0 0): cannot open directory "/var/lib": permission denied
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
/bin/bash: /home/eggert/.bashrc: Permission denied
Chromium 103.0.5060.134 snap

I think the journalctl lines for this uncommon failure were as follows:

Aug 01 08:28:57 day audit[3504]: AVC apparmor="DENIED" operation="capable" profile="/snap/core/13425/usr/lib/snapd/snap-confine" pid=3504 comm="snap-confine" capability=4 capname="fsetid"
Aug 01 08:28:57 day audit[3529]: AVC apparmor="DENIED" operation="mkdir" profile="snap-update-ns.firefox" name="/usr/share/libreoffice/help/" pid=3529 comm="5" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
Aug 01 08:28:57 day audit[3529]: AVC apparmor="DENIED" operation="open" profile="snap-update-ns.firefox" name="/var/lib/" pid=3529 comm="5" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Aug 01 08:28:57 day audit[3504]: AVC apparmor="DENIED" operation="open" profile="snap.firefox.firefox" name="/home/eggert/.bashrc" pid=3504 comm="desktop-launch" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Aug 01 08:28:57 day audit[3504]: SECCOMP auid=1000 uid=1000 gid=1000 ses=3 subj=? pid=3504 comm="firefox" exe="/snap/firefox/1589/usr/lib/firefox/firefox" sig=0 arch=c000003e syscall=314 compat=0 ip=0x7f6727ffc73d code=0x50000

Although I was running Firefox at the time, I had launched Firefox from the desktop, not from that terminal session.

Revision history for this message
Alberto Mardegan (mardy) wrote :

Hi Paul, thanks for the logs. There are clearly two very different issues here, and I'd recommend you to file a different bug for the "setlocale" warning (I searched in launchpad for a similar issue, but I haven't been able to find it).

The problem with the .bashrc error is that snaps are normally not allowed to read that file, yet the desktop integration helpers (the desktop-launch file is built embedding https://github.com/snapcore/snapcraft/blob/main/extensions/desktop/common/init inside it) used by chromium and firefox are bash scripts, and when bash is run non-interactively it will try to read the file pointed to by the BASH_ENV variable, which in your case is set to "$HOME/.bashrc".

I'm not sure what's the proper solution here: the fact that the user is free to specify any file name in $BASH_ENV means that we cannot just hardcode a rule in the AppArmor profile to let the snap read @{HOME}/.bashrc. It might make sense to change the snapcraft desktop helper script to pass the "-p" option to /bin/bash, in order to avoid reading $ENV and $BASH_ENV, but we risk breaking some user's setup.

One option would be to elect a specific value for $BASH_ENV which we declare to support and allow all snaps to read. Something like "$HOME/.bash_env"; on the other hand, before doing that I'd like to understand the use-case, because this variable is not commonly used. Does anything break if you unset it?

If you don't see behavioural changes in the applications, then we might just close the issue and let the warning stay, since it's mostly harmless.

Revision history for this message
Paul Eggert (eggert-cs) wrote :

Since AppArmor is designed to sandbox Firefox, it would make sense for the snapcraft desktop helper script to pass -p to /bin/bash. After all, lots of things can go wrong if the user overrides standard shell utilities.

I'm not sure why Bash is ever used when starting these browsers, though, since you're just scripting and surely don't need or use Bash's features. The snap packages for Chromium and Firefox already require Dash, so why not use Dash everywhere?

I reported the locale problem separately, as Launchpad Bug#1983399.

Revision history for this message
Alberto Mardegan (mardy) wrote :

Thanks Paul, I've added the snapcraft project to the bug, since the scripts are coming from there. Let's see if the "-p" switch can be added, or if there are other solutions.

Revision history for this message
Paul Eggert (eggert-cs) wrote :

A response to Bug #1983399 suggested that I file a bug report upstream as well, to snapd-desktop-integration, so I've done that here:

https://github.com/snapcore/snapd-desktop-integration/issues/22

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.