CentOS 8: /var/lib/snapd/snap/bin was not found in your $PATH

snapd
1

On a freshly installed/updated CentOS 8.1 virtual machine (default Workstation installation) I see the following warning when installing any snap:

$ sudo snap install --beta authy
Warning: /var/lib/snapd/snap/bin was not found in your $PATH. If you've not restarted your session
         since you installed snapd, try doing that. Please see https://forum.snapcraft.io/t/9469
         for more details.

authy (beta) 1.8.0 from Authy (authy-twilio) installed
$

Yet /var/lib/snapd/snap/bin is in my $PATH:

$ systemctl --user show-environment | grep ‘^PATH’
PATH=/home/<username>/.local/bin:/home/<username>/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/var/lib/snapd/snap/bin
$

While this error message seems innocuous (the installed snaps do run) it is really annoying and should be fixed as it confuses end-users who may mess up their machine in an attempt to fix an error which doesn’t exist (see for example CentOS 8 snapd install of Authy doesn't show up in applications folder).

Although snapd generates SELinux errors (far too often) this issue is not necessarily related to SELinux as it happens in permissive mode too (after sudo setenforce 0).

Also happens both in X11 and wayland graphical sessions.

2

I replied in the other topic before I noticed this one.

This is a know problem caused by using secure_path in sudo configuration in Fedora and RHEL. See
https://bugzilla.redhat.com/show_bug.cgi?id=1691996 for more details. Unfortunately, there’s no known way for packages to drop-in configuration files to tweak that setting. Using sudo -E does the trick but IIRC it preserves too much of the environment and is thus not recommended.

Do you have the audit log? We have a bunch of tests that run though some common scenarios to check that the current policy is sufficient. I’ve seen very fewer bugs being reported within the last couple of months too. If you see errors, please either post the audit log in a new topic or file a bug in RHBZ and I’ll look into it.

1 Like
3

Ah right, it’s easy to reproduce on CentOS 8 and Fedora 31:

$ cat ./foobar.sh
#!/bin/sh
echo $PATH
$ 
$ sudo ./foobar.sh 
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$

Unfortunately sudo -E does not help, at least on Fedora 31 option --preserve-env=PATH is required:

$ sudo -E ./foobar.sh 
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$ 
$ sudo --preserve-env=PATH ./foobar.sh 
/home/<username>/.local/bin:/home/<username>/bin:/usr/share/Modules/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/var/lib/snapd/snap/bin
$

I don’t know why option -E doesn’t work, from the man page:

-E, --preserve-env
             Indicates to the security policy that the user wishes to preserve their existing environment variables.  The
             security policy may return an error if the user does not have permission to preserve the environment.

Perhaps I need extra permissions for some of the environment variables that are changed by -E, but not for PATH.

4

That said, this warning really does more harm than good. Suggestions:

  • Get rid of the warning on Fedora and EPEL machines. Perhaps detecting /etc/redhat-release is good enough for that purpose.
  • Ask @chipaca to update the post below and explain that the warning is expected and harmless on recent CentOS, RedHat and Fedora distibutions:
    How to fix snap binaries not found