Bug 1691996

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.

This is not my call. The sudo package would need adjusting to add "/var/lib/snapd/snap/bin" to the path.

(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.

What do you think about that?

*** Bug 1780712 has been marked as a duplicate of this bug. ***

Will that snipped be added to the snapd package so this bug can be closed?

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.

(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.

Then I'll give that a shot with the next update of snapd that I'm working on right now.

This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle.
Changing version to 32.

(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.

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
$

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
$

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.

This is not a bug in snapd then, it's something only sudo can fix...

(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?

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.

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.

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.

FEDORA-2020-7219488e72 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-7219488e72

FEDORA-2020-0d5e544db7 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-0d5e544db7

FEDORA-2020-12d53b8cf7 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-12d53b8cf7

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.

Thank for pushing a fix!

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.

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.

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.

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.

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.

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.