/snap/bin is not added to path for "sudo su"

Bug #1635101 reported by Trent Lloyd on 2016-10-20
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
snapd
Medium
Unassigned

Bug Description

All binaries from snaps appear to be installed into /snap/bin, which is added to the path using /etc/profile.d -- which is only executed for login shells.

This works fine for "sudo <snap command>", "sudo -i" and "sudo su -" but specifically does not get added to the path when using:
$ sudo su

This caused confusion for me, and also some users in the community when trialing the canonical-livepatch service. I believe it is not uncommon for people to use this command to get a root shell. This is also likely to be a confusion point for those using crontab, which appears to default to a very simple /bin:/usr/bin

I'm not really sure what the best path forward for this is, but I suspect this is likely to be a frequent cause of confusion if nothing else. It would be ideal to find a solution, or consider a way to not use a special snap path for binaries and perhaps link them into a system location already in the path such as /usr/local/bin

This would also be an issue for someone who installs the snapd package in the same shell session as installing and using a snap. Most likely for upgrade users on a server install (as fresh installs all ship with it now) -- this also happened to me.

Related bug:
https://bugs.launchpad.net/snappy/+bug/1593157 "Does not warn when /snap/bin is not in the path"

Oliver Grawert (ogra) wrote :

please see the manpage for su, the paths are re-set on purpose (custom bits like /usr/games and /usr/local are dropped too) ... to have a root shell please use sudo -s or sudo -i

Trent Lloyd (lathiat) wrote :

You are correct that this PATH behavior is expected and that sudo -i/sudo -s is preferred (I am trying to get out of this bad habbit myself already), but

My main point is more that this is likely to be a noticeable point of friction -- same with cron. If we consider snappy a first class citizen for installations, it is likely to be confusing that the tools are not in any of the standard paths - even /usr/local.

There is perhaps not a super ideal solution to this situation.. but I think it is worth thinking about.

Side note: the standard path set does include /usr/local, and /usr/games. It's only the profile.d stuff which isn't executed (which is expected). Standard path set appears to be /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

Zygmunt Krynicki (zyga) wrote :

This still happens on up-to-date Ubuntu 19.10 with snapd 2.42~pre2

affects: snappy → snapd
Changed in snapd:
status: New → Confirmed
importance: Undecided → Medium
Zygmunt Krynicki (zyga) wrote :

For the record: there is a broader bug where PATH is really not easy to configure across an operating system. There's some hope that systemd's environment generators will finally provide _the_ way to solve that problem and over time everything will be patched not to include a canned copy of the "correct" PATH.

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

Other bug subscribers