Bug 1691996 - Applications installed by Snap are inaccessible when run with sudo
Summary: Applications installed by Snap are inaccessible when run with sudo
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: sudo
Version: 32
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Radovan Sroka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1780712 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-23 04:38 UTC by Wheeler Law
Modified: 2020-10-01 02:39 UTC (History)
13 users (show)

Fixed In Version: sudo-1.9.2-1.fc34 sudo-1.9.2-1.eln103 sudo-1.9.2-1.fc32 sudo-1.9.2-1.fc33 sudo-1.9.2-1.fc31
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-09-15 15:06:33 UTC
Type: Bug


Attachments (Terms of Use)

Description Wheeler Law 2019-03-23 04:38:35 UTC
Description of problem:
Commands installed by snapd are inaccessible when run with sudo. The "Defaults secure_path" line in the /etc/sudoers file is not updated when snapd is installed to include the snapd app directory. 


Version-Release number of selected component (if applicable):
snapd-2.36.3-1.fc29.x86_64

How reproducible:
Very. 

Steps to Reproduce:
$ vagrant init generic/fedora29
$ vagrant up
$ vagrant ssh
$ sudo dnf install snapd
$ sudo ln -s /var/lib/snapd/snap /snap
$ sudo snap install node --classic --channel=10
$ sudo node

Actual results:
sudo: node: command not found

Expected results:
Node to fire up. 

Additional info:
This is a contrived example, and is quickly fixed by modifing the secure_path in the /etc/sudoers file, but I should note that this isn't an issue in other distros

Fedora 29 /etc/sudoers secure_path line:
Defaults    secure_path = /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin


Ubuntu 18.04 /etc/sudoers secure_path line:
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

Comment 1 Ben Cotton 2019-10-31 19:44:37 UTC
This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 2 Neal Gompa 2019-11-04 23:55:36 UTC
This is not my call. The sudo package would need adjusting to add "/var/lib/snapd/snap/bin" to the path.

Comment 3 Radovan Sroka 2019-11-05 09:45:24 UTC
(In reply to Neal Gompa from comment #2)
> This is not my call. The sudo package would need adjusting to add
> "/var/lib/snapd/snap/bin" to the path.

I don't like the idea about altering default secure_path.

But if you really need this, you can extend secure path in your own snippet in /etc/sudoers.d/.
This snippet will be part of you package.

Comment 4 Radovan Sroka 2019-11-07 13:55:04 UTC
What do you think about that?

Comment 5 Neal Gompa 2019-12-09 09:02:37 UTC
*** Bug 1780712 has been marked as a duplicate of this bug. ***

Comment 6 Wheeler Law 2020-01-27 14:51:45 UTC
Will that snipped be added to the snapd package so this bug can be closed?

Comment 7 Neal Gompa 2020-01-28 03:08:49 UTC
The problem is that I cannot _append_ with a sudoers.d snippet, as far as I can tell. That would mean I would accidentally blow away any changes by the admin in /etc/sudoers.

From my perspective, I think the only reasonable solution would be to add "/var/lib/snapd/snap/bin" to secure_path.

Comment 8 Radovan Sroka 2020-01-28 09:03:57 UTC
(In reply to Neal Gompa from comment #7)
> The problem is that I cannot _append_ with a sudoers.d snippet, as far as I
> can tell. That would mean I would accidentally blow away any changes by the
> admin in /etc/sudoers.
> 

Not really.

> From my perspective, I think the only reasonable solution would be to add
> "/var/lib/snapd/snap/bin" to secure_path.

You can actually do that and this is the right way how to do it.
You have to install a file in /etc/sudoers.d/ e.g. snap-sudo.conf.

It should contain something like:

Defaults    secure_path += /var/lib/snapd/snap/bin

This will extend the default secure path with this path and when we eventually
update it, it will extend the new one. Your snippet will never break anything.

Comment 9 Neal Gompa 2020-01-29 00:25:44 UTC
Then I'll give that a shot with the next update of snapd that I'm working on right now.

Comment 10 Ben Cotton 2020-02-11 15:40:05 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle.
Changing version to 32.

Comment 11 Maciek Borzecki 2020-02-12 13:23:23 UTC
(In reply to Radovan Sroka from comment #8)
> (In reply to Neal Gompa from comment #7)
> > The problem is that I cannot _append_ with a sudoers.d snippet, as far as I
> > can tell. That would mean I would accidentally blow away any changes by the
> > admin in /etc/sudoers.
> > 
> 
> Not really.
> 
> > From my perspective, I think the only reasonable solution would be to add
> > "/var/lib/snapd/snap/bin" to secure_path.
> 
> You can actually do that and this is the right way how to do it.
> You have to install a file in /etc/sudoers.d/ e.g. snap-sudo.conf.
> 
> It should contain something like:
> 
> Defaults    secure_path += /var/lib/snapd/snap/bin
> 
> This will extend the default secure path with this path and when we
> eventually
> update it, it will extend the new one. Your snippet will never break
> anything.

Trying this change locally, but it does not work. Neither appending, nor overwriting secure_path has any effect. The only way I can change what PATH is reset to is via /etc/sudoers.

Comment 12 Dimitri Papadopoulos 2020-04-24 09:43:29 UTC
I can reproduce that on a freshly installed Fedora 31 (and CentOS 8 for what it's worth):
$ sudo sudo cat /etc/sudoers.d/99-snapd.conf
# Allow snap-provided applications to work with sudo

Defaults    secure_path += /var/lib/snapd/snap/bin
$ 


Here is a small script to reproduce the problem:
$ cat ./foobar.sh
#!/bin/sh
echo $PATH
$ 


Clearly the secure path is not updated:
$ sudo ./foobar.sh 
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$ 


Additionally "sudo -E" does not help for unknown reasons:
$ sudo -E ./foobar.sh 
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$ 


I have to use "--preserve-env=PATH" instead:
$ 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
$

Comment 13 Dimitri Papadopoulos 2020-04-24 10:08:48 UTC
I thought this might be caused by file permissions but that's not the case. Changing from:
$ ls -lZ /etc/sudoers.d/99-snapd.conf
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0 105 Feb 13 21:35 /etc/sudoers.d/99-snapd.conf
$ 

to:
$ ls -lZ /etc/sudoers.d/99-snapd.conf
-r--r-----. 1 root root system_u:object_r:etc_t:s0 105 Feb 13 21:35 /etc/sudoers.d/99-snapd.conf
$ 

does not help.

For what it's worth the SELinux context is identical to that of /etc/sudoers:
$ sudo ls -lZ /etc/sudoers
-r--r-----. 1 root root system_u:object_r:etc_t:s0 4351 Mar 27 10:35 /etc/sudoers
$

Comment 14 Radovan Sroka 2020-04-24 10:48:34 UTC
The secure_path cannot be set or appended from included snippet. Sudo was designed like that.

Normally you can set/append anything from snippet but the secure_path is exception.

Sorry I did not realize that before.

Comment 15 Neal Gompa 2020-04-24 18:33:33 UTC
This is not a bug in snapd then, it's something only sudo can fix...

Comment 16 Neal Gompa 2020-04-24 18:33:58 UTC
(In reply to Radovan Sroka from comment #14)
> The secure_path cannot be set or appended from included snippet. Sudo was
> designed like that.
> 
> Normally you can set/append anything from snippet but the secure_path is
> exception.
> 
> Sorry I did not realize that before.

So then, I would need you to extend the "secure_path" setting in the sudo package by default. Would you please consider doing so?

Comment 17 Johannes Pfrang 2020-05-21 12:58:37 UTC
I just saw the `snapd` package having added this file to `/etc/sudoers.d` and was very confused by the `.conf` extension,
because sudoers(5) clearly states:


> The #includedir directive can be used to create a sudoers.d directory that the system package manager can drop
> sudoers file rules into as part of package installation.  For example, given:
>
>     #includedir /etc/sudoers.d
>
> sudo will suspend processing of the current file and read each file in /etc/sudoers.d, skipping file names that end
> in ‘~’ or __contain a ‘.’ character__ to avoid causing problems with package manager or editor temporary/backup files.


Moreover, renaming the file to `99-snapd` to attempt to fix this packaging mistake completely breaks sudo, because
instead of appending to the secure_path it clobbers it, so that it *only* contains `/var/lib/snapd/snap/bin`.

Please remove the broken snippet (probably also from upstream) since it is a serious footgun and doesn't actually work.
I also don't think snippets should have the ability to clobber `secure_path`, but that's a separate issue in and of itself.

Comment 18 Maciek Borzecki 2020-05-25 07:51:14 UTC
I'll remove that file when I update the snapd package to 2.45. The problem of snap commands not being available under sudo remains though.

Comment 19 Fedora Update System 2020-09-15 15:06:33 UTC
FEDORA-2020-7458404c2c has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 20 Fedora Update System 2020-09-15 15:06:36 UTC
FEDORA-2020-7219488e72 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-7219488e72

Comment 21 Fedora Update System 2020-09-15 15:15:02 UTC
FEDORA-2020-0d5e544db7 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-0d5e544db7

Comment 22 Fedora Update System 2020-09-15 15:15:51 UTC
FEDORA-2020-12d53b8cf7 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-12d53b8cf7

Comment 23 Fedora Update System 2020-09-15 15:21:32 UTC
FEDORA-2020-c788914609 has been pushed to the Fedora ELN stable repository.
If problem still persists, please make note of it in this bug report.

Comment 24 Maciek Borzecki 2020-09-15 17:05:40 UTC
Thank for pushing a fix!

Comment 25 Fedora Update System 2020-09-16 14:29:55 UTC
FEDORA-2020-0d5e544db7 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-0d5e544db7`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-0d5e544db7

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 26 Fedora Update System 2020-09-16 15:35:51 UTC
FEDORA-2020-12d53b8cf7 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-12d53b8cf7`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-12d53b8cf7

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 27 Fedora Update System 2020-09-16 18:56:49 UTC
FEDORA-2020-7219488e72 has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-7219488e72`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-7219488e72

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 28 Fedora Update System 2020-09-17 16:01:24 UTC
FEDORA-2020-0d5e544db7 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 29 Fedora Update System 2020-09-21 20:48:56 UTC
FEDORA-2020-7219488e72 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 30 Fedora Update System 2020-10-01 02:39:23 UTC
FEDORA-2020-12d53b8cf7 has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.