Changing $PATH for apt installs

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Changing $PATH for apt installs

Julian Andres Klode
Hi folks,

I'm planning to have apt set PATH to a sane value for running
dpkg, so that maintainer scripts are executed in a sanitized
environment. That value will be:

        PATH=/usr/sbin:/usr/bin:/sbin:/bin

The effect:

(1) There is no /usr/local, which prevents breakage from custom perl
    or python installation

(2) /snap/bin is not included either. This means that packages migrating
    to snaps will have to provide compatibility links (scripts?) in /usr
    - IIRC, lxd already does so, I'm not sure about other libraries.

Together, this ensures that deb packages only talk to deb packages.

Thanks,
Julian

--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Changing $PATH for apt installs

Jamie Strandboge-3
On Tue, 04 Dec 2018, Julian Andres Klode wrote:

> Hi folks,
>
> I'm planning to have apt set PATH to a sane value for running
> dpkg, so that maintainer scripts are executed in a sanitized
> environment. That value will be:
>
> PATH=/usr/sbin:/usr/bin:/sbin:/bin
>
> The effect:
>
> (1) There is no /usr/local, which prevents breakage from custom perl
>     or python installation
>
> (2) /snap/bin is not included either. This means that packages migrating
>     to snaps will have to provide compatibility links (scripts?) in /usr
>     - IIRC, lxd already does so, I'm not sure about other libraries.
>
I'm generally in favor of the change, but AFAICS, lxd does *not* do anything
with compatibility symlinks (it uses snap aliases instead, which live in
/snap/bin). lxd may have done this in the past (I vaguely remember something
about that), but snaps shouldn't be doing this and in fact, strict mode snaps
typically cannot (only lxd and a couple of other super-privileged snaps happen
to be able to, but that is considered bad form). As for deb-to-snap migrations,
that still isn't well defined (again, lxd has the ability to do whatever it
wants where most snaps cannot).

That said, debs should always declare their dependencies and atm, debs can't
declare a dependency on a snap. Therefore, including /snap/bin in the PATH is
wrong since its possible that a deb is missing a dependency and sometimes finds
it in /snap/bin. As such, +1 on the change. There might be things to reconsider
depending on how we want to handle deb to snap migrations and especially deb
dependencies on snaps (if that every becomes a thing), but that can wait until
later.

--
Jamie Strandboge             | http://www.canonical.com

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Changing $PATH for apt installs

Julian Andres Klode
On Tue, Dec 04, 2018 at 03:26:05PM -0600, Jamie Strandboge wrote:

> On Tue, 04 Dec 2018, Julian Andres Klode wrote:
>
> > Hi folks,
> >
> > I'm planning to have apt set PATH to a sane value for running
> > dpkg, so that maintainer scripts are executed in a sanitized
> > environment. That value will be:
> >
> > PATH=/usr/sbin:/usr/bin:/sbin:/bin
> >
> > The effect:
> >
> > (1) There is no /usr/local, which prevents breakage from custom perl
> >     or python installation
> >
> > (2) /snap/bin is not included either. This means that packages migrating
> >     to snaps will have to provide compatibility links (scripts?) in /usr
> >     - IIRC, lxd already does so, I'm not sure about other libraries.
> >
> I'm generally in favor of the change, but AFAICS, lxd does *not* do anything
> with compatibility symlinks (it uses snap aliases instead, which live in
> /snap/bin). lxd may have done this in the past (I vaguely remember something
> about that), but snaps shouldn't be doing this and in fact, strict mode snaps
> typically cannot (only lxd and a couple of other super-privileged snaps happen
> to be able to, but that is considered bad form). As for deb-to-snap migrations,
> that still isn't well defined (again, lxd has the ability to do whatever it
> wants where most snaps cannot).
I mean the .deb packages depending on snapd and installing the snap in the
pre(?)inst, like the lxd one in the archive:

jak@jak-t480s:/tmp$ apt download lxd
Get:1 file:/etc/apt/mirrors.list Mirrorlist [226 B]
Get:2 http://de1.archive.ubuntu.com/ubuntu disco/main amd64 lxd all 1:0.4 [11,1 kB]
Fetched 11,1 kB in 0s (81,5 kB/s)
jak@jak-t480s:/tmp$ dpkg -c lxd_1%3a0.4_all.deb  | grep usr/bin
drwxr-xr-x root/root         0 2018-10-10 18:28 ./usr/bin/
-rwxr-xr-x root/root        34 2018-09-12 22:09 ./usr/bin/lxc
-rwxr-xr-x root/root        34 2018-09-12 22:09 ./usr/bin/lxd



--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (849 bytes) Download Attachment